Threat Model

Understanding what Kairo protects against—and what it doesn't—helps you make informed decisions about your security setup. This document details the threats Kairo addresses and the assumptions underlying that protection.

Threats Kairo Mitigates

Threat: Device Theft

Scenario: Someone steals your phone or laptop with the Kairo extension installed.

Attack: Thief tries to sign transactions using your wallet.

Protection:

Your key share is encrypted with your passkey
Passkey requires biometric (fingerprint/face) or PIN
Without your biometric, the key share can't be decrypted
Even if decrypted, they still don't have the network share

Residual risk: If the thief also has your biometric or device PIN, they can sign transactions (but only those allowed by your policy).

Threat: Phishing Attack

Scenario: You click a malicious link that looks like a legitimate dApp.

Attack: Fake site requests you to sign a transaction that drains your wallet.

Protection:

Your policy only allows transactions to approved addresses
Even if you approve the signing request, it fails if the destination isn't in your allowlist
On-chain enforcement means the fake dApp can't bypass the check

Residual risk: If the malicious address is somehow in your allowlist, the transaction will succeed.

Threat: Browser Extension Compromise

Scenario: An attacker injects malicious code into the Kairo extension.

Attack: Modified extension tries to sign unauthorized transactions.

Protection:

Policy enforcement happens on-chain, not in the extension
Malicious extension can't mint fake receipts (requires on-chain transaction)
Vault validates receipt before authorizing signing
Network share won't participate without valid vault authorization

Residual risk: A compromised extension could still request signing of policy-compliant transactions.

Threat: Malware on Device

Scenario: Your device is infected with cryptocurrency-stealing malware.

Attack: Malware intercepts transactions, modifies destinations, or attempts direct key theft.

Protection:

Key share is stored encrypted in secure enclave
Policy checks happen on-chain, beyond malware's reach
Destination validation prevents address replacement attacks
Amount limits cap potential losses

Residual risk: Sophisticated malware might wait for you to legitimately unlock your key share and then race to sign malicious transactions.

Threat: Replay Attack

Scenario: Attacker captures a valid signing request and tries to reuse it.

Attack: Replay the request to sign the same transaction again or a similar one.

Protection:

Each PolicyReceipt is consumed (deleted) after use
IntentRecord in the vault prevents signing the same intent twice
Intent hash uniquely identifies each transaction

Residual risk: None for exact replays. Different transactions require new receipts.

Threat: Backend Compromise

Scenario: An attacker gains access to Kairo's backend servers.

Attack: Use server access to sign transactions or mint fake receipts.

Protection:

Backend can't sign without your local key share
Backend can't mint receipts without the transaction passing policy (on-chain)
Vault authorization happens on-chain with full verification
All actions are logged in immutable custody trail

Residual risk: A compromised backend could potentially refuse to participate in signing (denial of service) but cannot steal funds.

Threat: Seed Phrase Theft

Scenario: Traditional wallets lose funds when seed phrases are stolen.

Attack: Phishing, social engineering, or data breach exposes seed phrase.

Protection:

Kairo doesn't use seed phrases
Your key share is useless without the network share
No single secret gives complete access

Residual risk: If you export your private key for backup purposes and that backup is stolen, you're in the same situation as seed phrase theft (though policy still helps).

Threat: Clipboard Hijacking

Scenario: Malware monitors your clipboard and replaces copied addresses.

Attack: You copy a friend's address, malware replaces it with attacker's address.

Protection:

Destination allowlist prevents sending to unexpected addresses
Policy shows and verifies the actual destination
Named addresses make mismatches obvious in approval UI

Residual risk: If you've whitelisted many addresses, you might approve a swapped address that happens to be on your list.

Threat: SIM Swap / 2FA Bypass

Scenario: Attacker takes over your phone number and bypasses SMS-based 2FA.

Attack: Access your exchange accounts, reset passwords, drain funds.

Protection:

Kairo uses passkeys, not SMS-based authentication
Passkeys are hardware-bound, not tied to phone numbers
Network share requires cryptographic proof, not SMS codes

Residual risk: None from SIM swap specifically. Device compromise is a separate threat.

Threats Kairo Cannot Fully Mitigate

Threat: Complete Device Compromise

Scenario: Attacker has full access to your device AND your biometrics/PIN.

Impact: They can sign any transaction your policy allows.

Why it's limited:

Policy limits the damage (spending caps, allowlists)
Custody trail shows exactly what happened
But within policy bounds, they can act

Mitigation:

Strong biometrics over device PIN
Short auto-lock timeouts
Consider hardware key for passkey
Restrictive policy limits exposure

Threat: Policy Misconfiguration

Scenario: You configure a policy that allows more than intended.

Impact: Transactions you didn't intend might be approved.

Why it's limited:

Kairo enforces your policy exactly
If your policy is permissive, so is Kairo

Mitigation:

Start with restrictive defaults
Add addresses individually as needed
Review and test your policy
Don't use "allow all" configurations

Threat: User Approval of Malicious Transaction

Scenario: You review a transaction and approve it, but it's actually malicious.

Impact: Transaction goes through because you approved it.

Why it's limited:

Kairo can't read your mind
If you approve a transaction to an allowed address, it signs

Mitigation:

Carefully review transaction details
Use descriptive names for allowed addresses
Don't rush through approval screens
Set amount limits as a safety net

Threat: Smart Contract Vulnerabilities

Scenario: You interact with a DeFi protocol that has a bug.

Impact: Protocol bug drains your approved deposit.

Why it's limited:

Kairo protects signing, not contract execution
Once signed, the transaction executes as written
Protocol vulnerabilities are outside Kairo's scope

Mitigation:

Only use audited protocols
Start with small amounts
Monitor protocol security news
Consider smart contract insurance

Threat: Network-Level Attacks

Scenario: Sui blockchain or Ika network is compromised at a fundamental level.

Impact: Could potentially affect policy enforcement or signing.

Why it's limited:

These are foundational security assumptions
Kairo's security depends on Sui's BFT and Ika's threshold cryptography

Mitigation:

These networks have significant security resources
Vulnerabilities would likely be patched quickly
Defense in depth (policy + keys) provides layers

Threat: Zero-Day Exploits

Scenario: Unknown vulnerability in browser, OS, or cryptographic libraries.

Impact: Could bypass security measures.

Why it's limited:

Can't defend against unknown attacks
This applies to all software

Mitigation:

Keep systems updated
Multiple security layers mean one compromise doesn't mean total loss
Kairo monitors for security issues

Trust Assumptions

For Kairo's security model to hold, we assume:

| Component | Assumption | |-----------|------------| | Your device | Not persistently compromised with root access | | Your passkey | Protected by secure hardware and biometrics | | Sui network | Byzantine fault tolerant, consensus works | | Ika network | Threshold cryptography is secure | | Cryptography | Standard algorithms (keccak256, secp256k1) are secure | | You | Review transactions before approving |

Risk Summary

| Threat | Kairo Protection | Residual Risk | |--------|------------------|---------------| | Device theft | Key encrypted with passkey | If biometrics compromised | | Phishing | Policy blocks unknown addresses | If address is allowlisted | | Malware | On-chain enforcement | Sophisticated attacks | | Extension compromise | On-chain policy | Within policy bounds | | Backend compromise | Can't sign without user share | Denial of service | | Replay attacks | Receipt consumption | None | | Clipboard hijacking | Allowlist validation | If swapped address allowed | | Full device + bio compromise | Policy limits | Within policy limits | | Policy misconfiguration | Enforces as configured | User error | | Smart contract bugs | N/A (out of scope) | Full | | Network attacks | Depends on Sui/Ika | Foundational risk |

Recommendations by Risk Tolerance

High Value / Low Risk Tolerance

Strict allowlist with minimal addresses
Low spending limits
Taproot-only for Bitcoin
Short policy expiration (renew periodically)
Multiple devices with independent passkeys
Regular audit trail review
Hardware security key for passkey

Medium Value / Normal Use

Allowlist with common DeFi protocols
Reasonable spending limits
Cloud-synced passkey for convenience
Periodic policy review
Automated verification

Lower Value / Higher Convenience

Broader allowlists
Higher or no spending limits
Standard passkey setup
Less frequent review

Staying Secure

Start restrictive — You can always add permissions
Review before approving — Don't rush signing
Keep software updated — OS, browser, and extension
Monitor your trail — Check custody events periodically
Have recovery ready — Don't wait until you need it
Report suspicious activity — To Kairo and relevant authorities

Next Steps

Security Model — How protections are implemented
Custody Verification — Verify your transaction history
Creating Policies — Configure appropriate protection