Trust Verification Challenge
This describes how trust verification occurs
Overview
GetTrusted's Challenge and Response Verification is a real-time identity verification system that enables secure authentication during live conversations or interactions. The system uses device-to-device cryptographic challenges with hardware-backed signatures, ensuring that the person you're communicating with is truly who they claim to be. We do require trusted contacts as only those that you trust already can be exploited to get you to act.
Key Security Features:
Zero-Knowledge Server: Backend never sees plaintext challenge data
Hardware-Backed Signatures: All signatures verified from Secure Enclave/StrongBox/TPM
End-to-End Encryption: ECIES encryption ensures only recipient device can decrypt
Real-time Delivery: WebSocket (foreground) or FCM push (background) delivery
Bilateral Trust: Both parties maintain local verification history
Process Overview
Alice (the Challenger) wants to verify Bob's identity during a phone call or video chat. She initiates a verification challenge that Bob must approve in real-time from his device.
Alice's Perspective (Challenger)
Bob's Perspective (Responder)
Process Flow Diagram
sequenceDiagram
participant Alice Device
participant Alice Secure Enclave
participant GetTrusted Backend
participant Bob Device
participant Bob Secure Enclave
Note over Alice Device,Bob Secure Enclave: Phase 1: Challenge Initiation
Alice Device->>Alice Secure Enclave: Sign verification challenge
Alice Secure Enclave-->>Alice Device: Hardware signature
Alice Device->>GetTrusted Backend: POST /verification/challenge
Note right of Alice Device: ECIES encrypted with Bob's public key<br/>Signed with Alice's device key
Note over Alice Device,Bob Secure Enclave: Phase 2: Device Discovery & Delivery
GetTrusted Backend->>GetTrusted Backend: Discover Bob's devices<br/>(master_identity → device_identities)
GetTrusted Backend->>GetTrusted Backend: Store challenge in Redis (10min TTL)
alt Bob App in Foreground
GetTrusted Backend->>Bob Device: WebSocket: verification_challenge
else Bob App in Background or WebSocket Failed
GetTrusted Backend->>Bob Device: FCM Push: verification_challenge
end
Note over Alice Device,Bob Secure Enclave: Phase 3: Challenge Decryption & Display
Bob Device->>Bob Secure Enclave: Decrypt challenge
Bob Secure Enclave-->>Bob Device: Decrypted challenge data
Bob Device->>Bob Device: Verify Alice's signature<br/>Display challenge UI
Note over Alice Device,Bob Secure Enclave: Phase 4: User Response
Bob Device->>Bob Secure Enclave: Sign approval response
Bob Secure Enclave-->>Bob Device: Hardware signature
Bob Device->>GetTrusted Backend: POST /verification/response
Note right of Bob Device: ECIES encrypted with Alice's public key<br/>Signed with Bob's device key
Note over Alice Device,Bob Secure Enclave: Phase 5: Response Delivery
GetTrusted Backend->>GetTrusted Backend: Validate responder<br/>Calculate latency<br/>Update Redis
alt Alice App in Foreground
GetTrusted Backend->>Alice Device: WebSocket: verification_response
else Alice App in Background or WebSocket Failed
GetTrusted Backend->>Alice Device: FCM Push: verification_response
end
Alice Device->>Alice Secure Enclave: Decrypt response
Alice Secure Enclave-->>Alice Device: Decrypted response data
Alice Device->>Alice Device: Verify Bob's signature<br/>Update verification history<br/>Show resultCryptographic Security
ECIES Encryption (End-to-End)
Challenge Encryption (Alice → Bob):
1. Get Bob's device public key (P-256 ECDSA)
2. Generate ephemeral key pair
3. Derive shared secret using ECDH
4. Derive encryption key using HKDF-SHA256
5. Encrypt challenge data using AES-256-GCM
6. Base64 encode for transmissionChallenge Decryption (Bob's Device):
1. Base64 decode encrypted blob
2. Extract ephemeral public key
3. Derive shared secret using Bob's device private key (hardware-only)
4. Derive decryption key using HKDF-SHA256
5. Decrypt using AES-256-GCM
6. Verify message integrityECDSA Signatures (Hardware-Backed)
Alice's Device Signature:
1. Hash challenge data using Blake3
2. Sign hash with device private key (Secure Enclave operation)
3. Include signature in encrypted payload
4. Signature proves Alice's device authorized this challengeBob's Signature Verification:
1. Extract Alice's device certificate from challenge
2. Get Alice's public key from certificate
3. Verify signature using P-256 ECDSA
4. Validates challenge is from Alice's hardware-backed deviceSecurity Guarantees
End-to-End Encryption
Server never sees plaintext challenge or response data
Only Alice's and Bob's devices can decrypt messages
ECIES provides perfect forward secrecy per session
Hardware-Backed Authentication
All signatures from Secure Enclave/StrongBox/TPM
Private keys never leave hardware security modules
Device attestation tokens verify hardware security level
Replay Attack Protection
Cryptographic nonce in each challenge (unique)
Challenge expiration (10-minute TTL in Redis)
Timestamp validation prevents old challenges
Man-in-the-Middle Protection
Mutual certificate verification required
PKI trust chain: Device → Master → Root CA
Signature validation before showing challenge UI
Bilateral Trust History
Alice stores: "I challenged Bob at timestamp X, he approved"
Bob stores: "Alice challenged me at timestamp X, I approved"
Verification history immutable and hardware-signed
Strategic Implications
Replacing "Trust Me" Phone Calls
Traditional Problem:
Alice: "Hey Bob, can you confirm you're on this call?"
Bob: "Yeah, it's me."
Alice: "Can you say something only you would know?"
Bob: "Remember that meeting last week?"
Alice: (Still unsure if voice could be AI/deepfake)GetTrusted Solution:
Alice: [Taps "Verify Identity" in app during call]
Bob: [Receives push: "Alice is verifying your identity" - taps Approve]
Alice: ✓ Bob verified via hardware attestation - Secure Enclave signature validatedDocument Version: 1.0 Last Updated: 2025-10-10 SDK Version: gettrusted-sdk-dual v2.0 API Version: gettrusted-api v1.0
Last updated