Your identity is a key that never leaves your phone.
No password. A public log proves it.

Alien Lights Identity

Your key stays on your phone

An ML-DSA-65 (FIPS 204) key is made on your phone. We keep only the public half.

Only you can open it

Hardware-backed Android Keystore. Fingerprint, face or PIN opens a 15-second window.

Anyone can check our work

Every key event goes into a public, hash-chained, double-signed transparency log.

ML-DSA-65FIPS 204 signatures
ML-KEM-768FIPS 203 key wrapping
AES-256-GCMencryption at rest
Argon2idrecovery password
15 sbiometric unlock window
Explain it like I'm 5 · 60 seconds

A wax stamp, a steel safe and a doorman

  1. Make a stampYour phone creates a one-of-a-kind wax stamp. That is your key.
  2. Lock it awayThe stamp lives in a tiny steel safe inside your phone.
  3. Open with youThe safe opens for your face or fingerprint. Just 15 seconds.
  4. Doorman hands a sheetOur server gives you one blank sheet. Single use.
  5. Stamp itThe doorman checks your stamp against a drawing of it. Match: you are in.
  6. Write it down, publiclyEvery key change goes in a public notebook. Nobody can erase a page.

Why no password? The doorman checks your stamp, not a secret word. There is nothing to phish or leak.

01 · On the phone

Your key lives in a hardware safe

Your phone makes the root key and locks it with a hardware-backed Keystore key. We never receive it.

  • ML-DSA-65 root key, made on your phone
  • Wrapped with AES-256-GCM at rest
  • StrongBox or Knox Vault when present, else TEE
  • ML-DSA-65
  • AES-256-GCM
  • StrongBox / TEE
Technical detail
  • The wrapping key is an AES-256-GCM key in the Android Keystore. StrongBox is requested first; Samsung routes that to Knox Vault. Otherwise a TEE-backed key is used.
  • The key is authentication-bound: every use needs a check, with a 15-second validity window. A strong biometric or the screen-lock credential qualifies.
  • ML-DSA signing runs in app memory after unwrap, because no shipping secure element runs ML-DSA.
  • Only standard Android Keystore and BiometricPrompt APIs are used. No proprietary SDK.
  • On Android 12 and newer the app reads the protection level from the key's security-level attribute and shows it in Settings. Older versions distinguish hardware from software.
  • With no secure screen lock, Android cannot bind the key to you. The app shows a banner asking for a lock.
  • Validated on real hardware: the installed release app registered an identity against the live production API on a Samsung Galaxy S25 FE. Hardware key protection read green, the Keystore held the AES-256-GCM wrapping key in StrongBox (Knox Vault), and an on-device sign and verify round trip passed. Other devices may land on TEE or software protection, which the app reports in Settings.
Protection levels the app reports Four outcomes, from strongest to weakest: StrongBox or Knox Vault, a separate secure chip; TEE, an isolated area inside the main chip; software only; and no screen lock, where the key cannot be tied to you. StrongBox / Knox VaultBest Separate secure chip with its own CPU TEEGood Isolated area inside the main chip Software onlyWeak The OS holds the key. The app says so. No screen lockUnbound The key cannot be tied to you. The app asks for a lock.
Protection levels the app reports
Where the key lives on your phone Three layers inside the phone. App memory holds the plain key only while unlocked and is cleared 60 seconds after you leave. App storage holds only the AES-256-GCM encrypted key. The Android Keystore holds the wrapping key, which never leaves the hardware. The server holds only your public key. Your phone 1 · App memorytemporary Plain key, only while unlocked Cleared 60 s after you leave loads after a fresh check 2 · App storage Encrypted key (AES-256-GCM) Useless without the wrapping key unwrapped in hardware 3 · Android Keystore Wrapping key never leaves hardware StrongBox / Knox Vault, else TEE Alien Lights server Holds: your public key Never has: private key, fingerprint, password
Where the key lives
02 · Biometric gate

It opens for you, for 15 seconds

Your fingerprint, face or PIN opens a 15-second window. The app locks itself 60 seconds after you leave.

  • Biometric-gated Keystore unlock
  • Sending re-checks after 2 minutes
  • Locking clears keys, tokens and caches
  • 15 s window
  • 60 s auto-lock
  • 2 min re-check
Technical detail
  • The 15 seconds limits when the Keystore performs wrap and unwrap operations. A key already in memory stays there until auto-lock.
  • Auto-lock fires 60 seconds after the app goes to the background and drops keys, tokens and decrypted caches.
  • Sending needs a fresh check if the last one was over 2 minutes ago.
  • On Android 9 and 10 the combined strong-biometric-or-PIN prompt is unavailable. The app accepts weak biometrics or the PIN there.
Unlock timeline Five steps. You open the app with a fingerprint, face or PIN. A 15-second window opens. The hardware unwraps the key and the app signs. When you leave the app a 60-second countdown starts. Then the app locks and clears keys from memory. 15 s 1 Open the appFingerprint, face or PIN 2 15-second window opensThe hardware may unwrap the key 3 Unwrap and signA login challenge or a message 4 You leave the appA 60-second countdown starts 5 Auto-lockKeys cleared from memory
Unlock timeline
03 · Passwordless

Sign in by signing a challenge

The server sends a one-time challenge. Your phone signs it. The server checks the signature against your public key.

  • No password to phish or leak
  • Each challenge works once, for 120 seconds
  • A replayed signature fails
  • ML-DSA-65
  • 120 s nonce
  • 1 h session token
Technical detail
  • The phone signs the exact text the server returns: a domain-separated prefix, the identity UUID and the nonce (UTF-8, ML-DSA-65).
  • The server rejects revoked identities and burns the nonce on first use.
  • The phone repeats the handshake silently when a session expires. It needs the key to be openable at that moment.
  • The session token is a JWT valid for 1 hour, held in memory only. Signing out drops it.
Passwordless sign-in The phone asks for a challenge. The server returns a one-time nonce valid for 120 seconds. After a fingerprint check the phone unwraps its key and signs with ML-DSA-65. The server verifies the signature with the stored public key, burns the nonce and returns a one-hour session token. Your phone Server 1 · Ask for a challenge 2 · One-time nonce, valid 120 s 3 · Fingerprint, face or PIN Hardware unwraps, ML-DSA-65 signs 4 · Signature + nonce 5 · Server checks Public key matches, nonce burned 6 · Session token (JWT, 1 h)
Passwordless sign-in handshake
04 · Zero-knowledge recovery

Lose your phone, keep your identity

A recovery password encrypts a backup of your keys on your phone. We store the encrypted blob and cannot open it.

  • Argon2id on the phone: 64 MiB, 3 passes
  • 5 wrong tries, then escalating lockouts
  • We never see the password or the keys
  • Argon2id
  • AES-256-GCM
  • Zero-knowledge
Technical detail
  • master = Argon2id(password, salt, m = 64 MiB, t = 3, p = 1) runs on the phone. HKDF-SHA256 with different labels derives an encryption key and a separate login verifier. Only the verifier and the AES-256-GCM blob are uploaded.
  • Lockouts per address: 15 minutes, 1 hour, 4 hours, 16 hours, then 24 hours.
  • Lockouts do not stop offline guessing against a stolen blob. The app accepts only strong passwords: about 60 estimated bits, or six random words from the EFF list.
  • Restore decrypts and signs in first, then writes. A wrong password, lockout or network drop leaves the phone untouched.
  • The replacement phone's own Keystore key re-wraps the restored keys.
Moving to a replacement phone On your phone a strong recovery password is stretched with Argon2id, then encrypts your keys with AES-256-GCM, producing an encrypted blob and a separate login verifier. The server stores both and can open neither, and it rate-limits wrong guesses. On the replacement phone the same password produces the verifier, the blob arrives and is decrypted locally, then the keys are sealed in that phone's hardware. 1 · Recovery passwordyour phone Strong: ~60+ bits or six random words 2 · Argon2id, then AES-256-GCMyour phone Encrypted blob + separate verifier 3 · Server stores bothserver Opens neither. 5 wrong tries, then lockout 4 · Same password, replacement phonenext phone The verifier proves it. Key stays local 5 · Blob arrives, opens on the phone 6 · Sealed in this phone's hardware
Moving to a replacement phone
05 · Transparency

A public log anyone can check

Every key event goes into a public, hash-chained, double-signed log. A short proof confirms any single entry.

  • Each entry cites the hash of its predecessor
  • Signed with ML-DSA-65 and Ed25519
  • Merkle inclusion proofs, as in RFC 6962
  • Public keys and metadata only. No secrets
  • Hash-chained
  • Double-signed
  • RFC 6962 proofs
Technical detail
  • A forged key cannot hide. Its entry is permanently dated and signed, and every later entry must cite the correct hash.
  • This is the Certificate Transparency design (RFC 6962), applied to identity keys.
  • An inclusion proof carries O(log n) sibling hashes. The verifier rebuilds the signed root without reading other entries.
  • Fetch the raw log at /api/identity/transparency/log and re-derive every hash yourself.
The public log: hash chain and inclusion proof Top: four log entries, each citing the hash of its predecessor. Bottom: a Merkle tree of four entries. To prove entry 2 is in the log, the server sends two hashes, entry 1 and the right-hand subtree. The verifier recombines them with entry 2 to rebuild the signed root. Entry 1signed Entry 2signed Entry 3signed Entry 4signed Each entry cites the hash of its predecessor Prove entry 2 with just 2 hashes Signed root hash hash Entry 1 Entry 2 Entry 3 Entry 4 entry you check the 2 hashes sent
Hash chain and inclusion proof
06 · Threat model

If something goes wrong, here is what an attacker gets

Stolen phone, lockedNothing usable

The key opens only for your fingerprint, face or PIN.

Stolen phone, unlockedA short window

15 s per check. Auto-lock 60 s after you leave the app.

Stolen server databasePublic keys, sealed blobs

Nothing in it can sign in as you.

Stolen recovery blobAn encrypted file

AES-256-GCM, opened only by your strong recovery password.

Future quantum computerBuilt for it

ML-DSA-65 and ML-KEM-768 are NIST post-quantum standards.

Phone with weaker hardwareLevel varies

StrongBox, TEE or software. The app shows which you have.

07 · Under the hood

Post-quantum math from NIST, doubled up

Tokens and log entries carry two signatures: ML-DSA-65 and Ed25519. Forging one means breaking both.

  • Every private key we store is wrapped with ML-KEM-768 + X25519
  • One Durable Object per identity. No shared rows
  • Standard OIDC: "Sign in with Alien Lights"
Technical detail
  • Hybrid signatures cover both risks: ML-DSA-65 resists quantum attackers, while Ed25519 has decades of cryptanalysis behind it. Both sign the same bytes.
  • Private keys at rest are wrapped by a fresh ML-KEM-768 + X25519 encapsulation against a rotatable root key, not one static secret.
  • Server-held keys rotate monthly on each identity's signup anniversary, scheduled by that identity's own Durable Object alarm. Phone-held root keys rotate when you choose.
  • The OIDC provider uses authorization code + PKCE. Tokens are ordinary JWTs with the ML-DSA-65 signature carried as an extension field.
  • Verification works offline with a cached public key. Read-only key endpoints serve a short-lived cache during a database outage. Writes and OIDC userinfo fail closed.
Try it live

Run real API calls on a test identity

Sign up, sign a message, verify offline, then audit the public log. Every call hits the production API.

Comparison

How it compares

documented   not publicly documented   partial. Source: each provider's public documentation, November 2026.
CapabilityGoogleMicrosoftLastWallAlien Lights
Hardware-bound, biometric key✓✓✓✓
Offline, on-device key generation by a public app✗✗◐✓
Post-quantum signature on that key✗✗✗✓
Post-quantum signed identity tokens✗✗✗✓
Zero-knowledge recovery◐◐✗✓
Public key log with inclusion proofs✗✗✗✓
Post-quantum key wrapping at rest✗✗✗✓
Works disconnected✗◐✓✓
Third-party audits, certifications✓✓✓✗
Technical detail
  • Google and Microsoft: passkeys are hardware-bound and biometric-gated with classical keys. Identity tokens are signed with the provider's own key. Recovery runs through the provider account.
  • Microsoft: cached-credential domain login covers disconnected enterprise use.
  • LastWall IDCommand: hardware-bound passkeys, PKI and PIV/CAC, and post-quantum key exchange. IDCommand Tactical targets disconnected and air-gapped use.
  • Offline key generation: Google and Microsoft create signing keys server-side. LastWall provisions hardware-bound keys through managed enterprise and government deployments rather than a public self-serve app.
  • Certifications: Microsoft FedRAMP High. LastWall Enterprise FedRAMP Moderate and DoD IL2. Google holds extensive audits.
FAQ

Quick answers

What if I lose my phone?

Restore on another phone with your recovery password. Without that password, nobody can recover the backup, including us.

What if someone steals my phone?

The key opens only for your fingerprint, face or PIN, and the app locks 60 seconds after you leave.

Can Alien Lights read my mail or keys?

No. We keep your public key and an encrypted backup we cannot open.

Does it work on a real phone?

Yes. The installed app registered against live production on a Samsung Galaxy S25 FE, with the key wrapped in Knox Vault and a sign and verify round trip passing. Each phone reports its own protection level in Settings.

Is it quantum-safe?

It uses NIST post-quantum standards: ML-DSA-65 (FIPS 204) and ML-KEM-768 (FIPS 203).

Why no password?

Passwords get phished and leaked. Your phone signs a one-time challenge instead.

Who can check the log?

Anyone. It is public, and every hash and signature can be re-derived.

Read the whitepaper

Identity is created on the phone. The private key stays there.

Sign up free Read the whitepaper