Security Model and Known Weaknesses
This document describes the not.bot™ security model: what the system guarantees, what threats each guarantee addresses, and where the known gaps are.
For the privacy properties of the system (what each party can and cannot learn), see the Privacy Architecture document. For the law enforcement access model, see the Law Enforcement & Accountability document.
Authenticity
Authenticity ensures that identities, signatures, and credentials originate from the parties they claim to originate from.
S1.1 Signatures cannot be forged. A valid not.bot signature requires the private key of the signing alias, stored in the device's encrypted database, protected by the device's secure element. Creating a signature requires biometric authentication or the device passcode at the moment of signing.
S1.2 Credentials cannot be forged. Julia Social signs credentials using delegated issuer key singletons. Forging a credential requires compromising these signing keys. If a delegated key is compromised, Julia Social melts the issuer key singleton, destroying it and invalidating all credentials it signed, then re-delegates to a fresh key.
S1.3 Site passes cannot be forged. Site passes are computed through a three-party multiparty computation among the user's app, the site's not.bot Verify server, and Julia Social. All three parties are required to produce a valid site pass.
S1.4 Identity cannot be impersonated without key compromise. The BLS signing keys controlling a user's alias DIDs are stored in an encrypted database whose encryption key is held in the device's secure element. Impersonation requires either extracting the signing key from a compromised device or breaking the underlying cryptography.
S1.5 Domain ownership for not.bot Verify is cryptographically verified. Each Verify server's DID is bound to its operator's domain through DNS TXT records. Julia Social issues domain name credentials to servers that prove domain ownership. Users who receive a verification request see the requesting domain name with cryptographic assurance that the request originates from that domain.
S1.6 Recovery requires validation by the user's configured Recovery Server operator(s). In the current single-operator configuration, validation requires possession of the passport used during enrollment. Future multi-participant configurations may support alternative validation methods determined by each operator's policy.
Integrity
Integrity ensures that data cannot be modified without detection.
S2.1 Signed messages cannot be modified. The cryptographic proof in a signature covers the message, credentials, timestamp, and nonce. Any change invalidates the proof.
S2.2 Credentials cannot be modified after issuance.
S2.3 Blockchain state cannot be falsified to a properly-connected client. The Chia blockchain uses proof-of-space-and-time consensus, maintained by approximately 30,000 nodes worldwide.
S2.4 The encrypted recovery bundle cannot be modified without detection.
S2.5 QR code signature data hosted by Julia Social cannot be modified without detection. The scanning app verifies the decrypted result against a hash embedded in the QR code. Any alteration to the stored data causes this verification to fail.
S2.6 Credential revocation cannot be hidden from a properly-connected not.bot Verify server. Revocation is recorded as a bit flip in a revocation bitfield on the Chia blockchain. Verify checks revocation status against the blockchain in real time at each credential presentation. Verify requires a synchronized blockchain node and will not accept credentials verified against an out-of-sync node. There is no caching of revocation state.
S2.7 Credentials have defined validity periods. Age credentials are valid from the first day through the last day of the calendar month in which they are issued. Site pass credentials never expire. All other Julia Social credentials (personal information, not.bot credential, domain name credentials) are valid for three years from the first day of the month of issuance. not.bot Verify rejects expired credentials regardless of revocation status.
Non-repudiation
Non-repudiation ensures that signers cannot deny having signed.
S3.1 Signatures are bound to the signer's DID and a specific point in blockchain history.
S3.2 Self-attested signature timestamps are embedded in the signed structure and cannot be modified independently.
S3.3 Nonces prevent replay and establish freshness.
S3.4 A signature produced in response to a not.bot Verify request embeds a complete copy of that request, which the Verify server signed. The signature countersigns the request, binding the signer and the requesting server into one non-repudiable record. The signer cannot deny producing the signature, and the requesting server cannot deny asking for it. No tooling extracts the embedded request today; it is present in every Verify signature as a latent property.
Availability
Availability ensures that users can access and use their identities when needed.
S4.1 Identity recovery is possible after complete device loss. Recovery requires the user's password (to decrypt the recovery bundle) and validation by the Recovery Server operator (currently requiring the user's passport).
S4.2 Credential verification does not depend on Julia Social's availability. The app verifies signatures using on-chain data from blockchain nodes. JAB code signatures are self-contained and require no server at all. Accessing the credential presentation data for a QR code signature does require Julia Social’s availability, but verifying it does not.
S4.3 Site operations using not.bot Verify do not depend on Julia Social's availability. Verify runs in the customer's own infrastructure with its own private blockchain nodes. Verify continues processing verification requests through extended Julia Social outages.
S4.4 Subscription lapse does not destroy identity. A user's DID, aliases, and key material persist on the blockchain and on their device regardless of subscription status.
S4.5 Age credentials can be refreshed without re-enrollment. Monthly age credential updates are handled by a three-party multiparty computation among the not.bot app, Julia Social, and the Escrow Server (operated by Praxis, the escrow agent), with neither Julia Social nor the Escrow Server learning the user's birthdate.
S4.6 Julia Social cannot selectively deny service to a specific person without first possessing a signature from one of that person's aliases. Identity operations (credential issuance, recovery endorsement, age credential refresh, faucet coin provision) depend on Julia Social's cooperation, but Julia Social has no mapping from real-world identities to root DIDs.
Resistance to key compromise
S5.1 Compromise of a user's device key is recoverable. The user can initiate recovery on a new device using their passport and recovery password, or perform an immediate rekey if they still control an enrolled device.
S5.2 Compromise of a user's password alone does not enable identity takeover. The password decrypts the recovery bundle, but downloading a recovery bundle requires a challenge/response signature from the root DID. An attacker with only the password cannot retrieve the bundle.
S5.3 Compromise of Julia Social's online signing keys enables credential forgery only until Julia Social cancels the delegation and melts the compromised issuer key singleton, invalidating all credentials that key signed. Julia Social limits the number of credentials signed with each issuer key singleton.
S5.4 Compromise of Praxis's systems does not enable credential forgery. The Escrow Server participates in credential issuance through MPC but does not hold Julia Social's signing keys.
S5.5 Compromise of a site's not.bot Verify keys does not enable impersonation of other sites. Each deployment's business DID and signature DIDs are independent, and each signature DID carries a domain credential that Julia Social issues after a DNS check, so a stolen key proves nothing for any domain but its own. Within the compromised site, the honest.bot credential's single-process enforcement surfaces the hijack: the moment a rogue instance starts, the legitimate server's credential is revoked, which signals the compromise. Planned response: an attacker who reached the site's OpenBao instance also holds its business DID key, so recovery resets the business DID that sits above the signature DIDs and re-establishes fresh domain credentials down the chain. This response is not implemented today.
Known security weaknesses
This section states known weaknesses in the current system alongside planned mitigations.
SW1: Single Recovery Server operator. Julia Social currently operates the only Recovery Server. When a user has only a single Recovery Server, and that Recovery Server operator is compromised or compelled to act maliciously, it can execute a malicious recovery and refuse to endorse cancellation. The 48-hour recovery pending window provides a detection opportunity (the legitimate user's app can observe the pending recovery on the blockchain), but the current single-operator model offers no defense if the operator is the attacker or cooperates with the attacker.
If a malicious recovery completes, the correct owner can still initiate a new recovery back to themselves, provided they retain access to their passport and recovery password, and provided they can secure the cooperation of their recovery server operator.
Planned mitigation: Multi-class, multi-participant recovery will allow users to configure multiple Recovery Server operators with threshold requirements (e.g., 2-of-3 operators must endorse). No single operator will be able to endorse or block a recovery unilaterally. Julia Social plans to open-source the Recovery Server software and support both third-party commercial and self-hosted recovery agents.
SW2: Malicious app update. A malicious or compromised app update published by Julia Social could extract BLS signing keys, enabling full impersonation. BLS12-381 keys are stored in the app's encrypted local database rather than the device's secure element, because no existing secure enclave or TEE hardware supports BLS12-381. The database encryption key is held in the secure element, preventing extraction by external attackers, but the app software has access to the decrypted keys during normal operation. A malicious update could exfiltrate these keys, the recovery bundle password, or any other data accessible to the app.
Mitigations: Independent code audits, app store review processes, and Julia Social's reputational and legal incentives to maintain user trust. These are trust-based constraints, not architectural ones.
SW3: Unaudited MPC protocols. The multiparty computation protocols used for credential issuance, site pass creation, and age credential computation have not yet received an independent security audit. A team of five PhD cryptographers from Galois, Inc., led by Dr. David Archer (Galois's principal researcher in secure multiparty computation), co-developed these protocols. Galois has done extensive MPC work for DARPA, IARPA, and the Department of Homeland Security. The provenance of the protocol design provides meaningful assurance, but it is not a substitute for independent verification.
Planned mitigation: An independent code audit by Least Authority is planned.
SW4: No liveness check at enrollment. The identity verification provider (Signicat) validates the passport's cryptographic authenticity but does not confirm that the person scanning the passport is its rightful holder. Someone in possession of another person's passport could enroll using that passport. The legitimate passport holder can recover the identity through the standard recovery process (S1.6), but during the period between fraudulent enrollment and successful recovery, the fraudulent enrollee controls the identity.
Mitigation: The recovery process provides remediation, not prevention.
SW5: Duplicate passport edge case. In the rare case where two identical passports exist for the same person (for example, a reissued passport where both old and new versions remain in circulation with identical personal information fields), two parties could each claim ownership of the same not.bot identity and alternately recover from one another. The duplicate detection hash is computed from personal information fields rather than document identifiers, so the system cannot distinguish which party is the legitimate owner.
Planned mitigation: None. This scenario is expected to be rare in practice.
SW6: Offline brute-force against recovery bundles. A compromised Recovery Server exposes encrypted recovery bundles to offline brute-force attack. The recovery bundle is encrypted with a key derived from the user's password using Argon2id with parameters meeting or exceeding OWASP guidelines. Downloading a recovery bundle under normal conditions requires a challenge/response signature from the root DID, preventing online attacks. But an attacker who obtains encrypted bundles through a Recovery Server compromise (see SW1) can attempt offline brute-force without rate limiting. The 8-character minimum password requirement provides insufficient protection if the user selects a low-entropy password.
Mitigations: Users should select a strong password or use a password manager. Open-sourcing the Recovery Server software (see SW1 mitigation) will allow users to self-host their recovery bundles, removing the Recovery Server operator as an attack surface.
SW7: Multi-device JAB code race condition. The multi-device setup flow displays a JAB code containing encrypted device-sharing data. An attacker who physically observes the victim and scans the JAB code first can win the race to retrieve the one-time setup code from the Recovery Server. The victim's device detects the race condition and warns the user to check their surroundings. The attacker cannot complete the takeover without also knowing the victim's password.
Mitigation: Users should treat any unexplained failure during multi-device setup as a security event and move to a private location before retrying.
SW8: No device attestation. Julia Social has not implemented device attestation. The app does not verify that it is running on genuine hardware rather than an emulator or modified device. iOS App Attest and Android Play Integrity API are available platform capabilities that would address this gap.
Status: Added to Julia Social's development queue. Not yet scheduled.
Recovery timing
Recovery restores a user's identity after device loss. The process has specific timing guarantees that create windows for detection and cancellation.
The root DID recovery transaction is submitted at t=0. If no cancellation occurs within 48 hours, the root DID recovery completes. The app then submits alias DID recovery transactions over the following 24 hours. Each alias recovery takes 48 hours from submission. The app becomes usable as soon as the first alias completes; aliases still pending appear flagged in the interface. Total worst-case recovery time is approximately five days.
Both initiating and canceling a recovery require authorization from the user's recovery agent(s). Recovery and cancellation verification must meet or exceed the user's enrollment level: a user who enrolled through a notbot1 partner (NIST IAL2) cannot recover via a notbot0 passport scan, but can recover through any notbot1 or notbot2 facility.
For the privacy implications of recovery (alias exposure to the Recovery Server), see PW1 in the Privacy Architecture document.