Security Model

The iuth security model operates on the principle of "Zero Trust at the Edge." We assume that any physical robot deployed in the real world is liable to be stolen, tampered with, or hacked.

Therefore, our architecture ensures that compromising a robot does not equal compromising the user's wallet.

1. Key Storage & Management

We implement a tiered key storage strategy to separate authority from execution.

A. The Controller Node (User's Device)

• Storage: The Master Private Key is stored within the mobile device's Secure Enclave (iOS) or Trusted Execution Environment (TEE) (Android).

• Access: Biometric authentication (FaceID/Fingerprint) is required to sign any transaction broadcast. The key never leaves the hardware security module of the phone.

B. The Managed Device (Robot)

• Storage: The robot holds only a Session Key (an ephemeral key pair).

• Protection: Ideally, this key is generated inside the robot's TPM (Trusted Platform Module) or HSM (Hardware Security Module), ensuring it cannot be extracted even if the attacker has physical access to the board.

• Scope: The Session Key has no direct access to funds. It is only authorized to sign requests sent to the Controller Node or to sign strictly limited interactions defined by the on-chain PDA.

2. The "Kill Switch" (Instant Revocation)

In the event of theft or loss, speed is essential. iuth provides a panic button mechanism.

• Mechanism: Since the robot's authority is validated against an on-chain PDA (Program Derived Address), the owner can send a single transaction to the Solana network to update the PDA status to REVOKED.

• Outcome:

  • The robot's Session Key is instantly blacklisted.

  • Any pending transactions are rejected by the smart contract.

  • The physical machine becomes financially inert ("bricked"), preventing the thief from using it to pay for services or access secure areas.

3. Smart Contract Guardrails

To mitigate the risk of software bugs or AI hallucinations (e.g., a robot trying to buy 1,000 coffees), we enforce logic at the protocol level.

• Velocity Limits: "Maximum 5 SOL spendable per 24 hours."

• Whitelist Only: "Can only interact with Verified Merchants (e.g., Official Tesla Chargers)."

• Cooldowns: "Minimum 10 minutes between transaction requests."

These rules are baked into the Solana Account state, meaning even if the robot's software malfunctions, the blockchain will reject the excessive transaction.

4. Hardware Attestation

To prevent "Device Spoofing" (where a hacker tries to pretend their laptop is your robot), iuth supports Remote Attestation.

• When a robot connects to the iuth App, it must sign a cryptographic challenge using its hardware-embedded key (TPM).

• If the signature does not match the registered hardware fingerprint, the app rejects the connection, ensuring you are only communicating with your actual machine.