The password is a conceptual mistake that has been enshrined in infrastructure for fifty years. It is a shared secret: you know it, and so does the server. If either party is compromised, the authentication is compromised. The browser’s job, historically, has been to help you manage this mistake at scale — password managers, autofill, breach-detection integrations. These are useful tools, but they are optimisations on top of a broken model.
Hardware-attested identity is a different model. Instead of a shared secret, you have an asymmetric key pair where the private key is generated inside a hardware security module and cannot be exported. The server never sees your private key. Neither does the browser. Neither does the operating system. The private key exists only inside the chip, and signing operations happen inside the chip. If an attacker compromises everything else on your machine, they still cannot extract the key.
This is not new technology. TPM 2.0 has been a required component of Windows-certified hardware since 2016. Apple’s Secure Enclave has been in every Mac since the M1 and in every iPhone since the 5S. What has been new is making this infrastructure usable for browser authentication without requiring the user to understand the underlying cryptography. That is what Dart’s identity layer does.
How TPM 2.0 works (briefly)
The Trusted Platform Module is a dedicated microcontroller on your motherboard (or integrated into the SoC on modern designs). It has its own processor, storage, and random number generator, physically isolated from the main CPU. The TPM can generate RSA, ECC, and (with firmware updates) post-quantum key pairs. It can perform signing operations using those keys. It cannot export the private key portion of those pairs in any mode of normal operation.
The TPM has a hierarchy of keys. At the root is the Endorsement Key (EK), which is generated during manufacturing and certified by the chip manufacturer. Above that, Dart generates what is called an Attestation Identity Key (AIK) — a key whose creation can be proven to have happened inside a genuine TPM. Above that, Dart generates user identity keys for specific applications (browser authentication, session signing) that are bound to the AIK.
The chain of trust is: chip manufacturer certifies the EK → EK certifies the AIK → AIK certifies the user identity key. A relying party (an enterprise SSO system, for example) can verify this chain and be confident that the key being used to authenticate was generated inside a real TPM, not in software that could be compromised.
Apple Secure Enclave
The Secure Enclave Processor (SEP) on Apple Silicon Macs provides equivalent guarantees via a different architecture. The SEP is an isolated ARM core with its own boot ROM, encrypted memory, and dedicated hardware random number generator. Keys generated in the SEP are protected by the SEP’s own hardware encryption; they cannot be extracted even by the main application processor running as root.
Apple exposes the SEP through the CryptoKit framework and the Security framework’s SecureEnclave API. Key generation, signing, and key agreement operations are available; key export is not, by design. The attestation mechanism differs from TPM 2.0 but provides similar semantic guarantees: a certificate that can be verified to chain to Apple’s manufacturing certificate authority, proving that the key was generated in genuine Apple hardware.
What Dart does with this
When you first launch Dart, it generates a hardware-bound identity key using whichever secure hardware is available on your machine: TPM 2.0 on Windows and Linux, Secure Enclave on macOS. This is your Dart identity key. It is used for:
Session signing. Every browser session that the Dart Agent participates in is signed with your identity key. This creates an audit trail that is attributable to your specific hardware, not just your account credentials.
Local semantic index encryption. The key used to encrypt your local browsing index (the data the Dart Agent uses for context) is derived from your hardware identity key. This means the index is bound to your hardware: it cannot be decrypted on a different machine, even if the files are copied.
Enterprise SSO attestation. On enterprise plans, Dart can present a hardware attestation to your organisation’s identity provider, proving that the browser session is running on a specific, enrolled device. This enables device-trust policies: you can configure your IdP to require hardware attestation before granting access to sensitive applications.
Post-quantum identity. New identity keys generated by Dart use ML-DSA (CRYSTALS-Dilithium, NIST FIPS 204) for signatures. This ensures that your identity keys are not vulnerable to Shor’s algorithm even if a cryptographically-relevant quantum computer becomes available.
What this means for the password
Dart does not eliminate passwords from the web. Servers still need to verify your identity, and most servers today accept passwords as primary authentication. What Dart changes is the browser’s role in that interaction.
For sites that support WebAuthn/FIDO2 passkeys, Dart uses the hardware identity key as the authenticator. The private key never leaves your hardware. The server receives a public key and a signed challenge. There is no shared secret to phish, breach, or guess. Dart makes passkey authentication the default where the site supports it, and makes the UX for passkeys significantly better than any other browser we are aware of.
For sites that still require passwords, Dart provides a password manager that is encrypted with your hardware identity key. The encryption happens locally; the password database is bound to your hardware in the same way the agent index is. Cloud backup of the password database is encrypted with your hardware key before leaving your device.
Attack scenarios this defeats
Credential theft from the browser store. Chromium’s password store is encrypted with the OS keychain, which is adequate for most threat models. Dart adds hardware binding: even if an attacker exports your password database file, they cannot decrypt it without your specific hardware chip.
Session token replay. If an attacker manages to extract a session token from browser memory (via a browser exploit or a compromised extension), they can normally replay that token from any machine. Dart’s session signing ties the session to your hardware attestation; a relying party that validates the attestation will reject a replayed token from a different device.
Phishing. Passkeys are phishing-resistant by design: the key material is tied to a specific origin (the site that created it). A fake login page at bank-login-secure.com cannot present a credential intended for bank.com. This is a property of the FIDO2 protocol, not of Dart specifically, but Dart makes passkeys the default rather than an opt-in.
Harvest-now-decrypt-later on authentication. For identity keys specifically (as distinct from session keys), hardware binding means there is nothing to harvest. The private key never leaves the chip. A future quantum computer cannot be pointed at a copy of it because no copy exists.
Limitations
Hardware-attested identity is not a complete security solution. It does not protect against:
- Attacks that operate at the hardware level, including physical access attacks on the TPM itself (which require significant expertise and equipment)
- Social engineering attacks where the user is persuaded to approve a fraudulent operation that the hardware chip will sign
- Bugs in the TPM firmware or the Secure Enclave implementation (which do exist and are patched by vendors)
- Sites that do not implement passkeys and fall back to password authentication, where the hardware binding provides no advantage
We document these limitations because honest security engineering requires stating what a system does not do, not only what it does. Hardware-attested identity moves the security floor substantially upward for browser-based authentication; it does not make browser authentication invulnerable.
If you are a security researcher with questions about Dart’s identity layer, write to security@dartbrowser.com. We welcome review and responsible disclosure.