HROT - Hardware Root Of Trust
TrustGrid uses Hardware Root of Trust (HRoT) technology to create a secure foundation for user identities and key management.
Biometric Binding with Privacy Protection (DCM + HME):
Initial Biometric Scan and Liveness Check: During initial app setup, a biometric scan (e.g., facial recognition) is performed. A standard called Direct Continuous Monitoring (DCM) verifies the liveness of the scan, ensuring it's not a spoof (like a picture).
Privacy-Preserving Hashing (HME): The live biometric data is then processed using a privacy-preserving hashing algorithm (HME). This one-way function creates a unique and irreversible hash value. This protects user privacy by not storing the actual biometric data on the device.
Key Pair Generation within HRoT: This unique hash, tied to the specific device's secure enclave (HRoT), is used to generate a cryptographic key pair within the enclave. This binding eliminates the need for passwords in future interactions.
HRoT for Secure Key Management:
Secure Storage: The HRoT, a secure processor within the user's device, acts as a tamper-proof environment to store the generated key pair securely. This key pair is unique to the user and the specific device.
Enhanced Security: The private key cannot be extracted from the HRoT, significantly reducing the risk of unauthorized access or theft.
DID Generation using HRoT:
PPK Generation from Biometric Hash: Following the biometric scan, liveness check, and HME, the resulting hash is used to generate the private key, its corresponding signature key, and the public key within the secure enclave/keystore.
Cryptographically Secure Random Seed Generation: To achieve the highest level of security, a cryptographically secure pseudo-random number generator (CSPRNG) within the HRoT generates a random seed. CSPRNGs are algorithms specifically designed to produce unpredictable and statistically random numbers ideal for cryptographic applications like key generation. 3. DID Creation using Public Key and Seed:
Utilizing Hyperledger Indy and Aries Framework libraries within the app, the public key (from step 1) and the random seed (generated in step 2) are used as inputs.
A secure hashing algorithm (e.g., SHA-256 or SHA-3) is applied to the combined data (public key + seed).
The resulting hashed value becomes the unique identifier acting as the seed for the user's DID generation on the network/ledger.
HRoT and Recovery Features:
While the solution prioritizes security by leveraging HRoT, it also acknowledges limitations in case of a lost phone:
Losing the Key Pair: Losing the phone results in losing the unique key pair stored within the HRoT. This key pair cannot be recreated due to the secure nature of the HRoT environment.
Optional Credential Backup: Users can opt-in to back up their credentials (not the private key) to an external storage of their choice (e.g., personal cloud storage/IPFS). This backup is encrypted using a PIN that's integrated with the key pair, ensuring access requires both the user's PIN or the specific key pair (lost with the phone). This backup allows restoring credentials on a new device without needing to re-obtain them from issuers.
New DID with Continuity: A new DID is generated on the new device but is linked to the previous DID for continuity.
This HRoT-based approach prioritizes security by:
Leveraging the HRoT for secure key generation, storage, and biometric binding seed generation.
Utilizing a privacy-preserving biometric binding process (DCM + HME).
Offering optional credential backup with user-controlled encryption.
Last updated