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)

1

Initiate verification

Alice initiates verification during an active conversation with Bob.

2

Discover Bob's device identities

App discovers Bob's device identities registered under his master identity.

3

Encrypt the challenge

Challenge is encrypted with Bob's device public key (ECIES encryption).

4

Sign the challenge

Signed with Alice's device key (hardware-backed ECDSA signature).

5

Deliver the challenge

Delivered via WebSocket (if Bob is in foreground) or FCM push (background).

6

Wait for response

Alice waits for response with UI showing "Waiting for verification..."

7

Receive response

Bob's response arrives encrypted and signed.

Bob's Perspective (Responder)

1

Receive notification

Bob receives push notification or WebSocket message with encrypted challenge.

2

Decrypt challenge

App decrypts challenge using Bob's device private key (hardware-only operation).

3

Validate signature

Validates Alice's signature using her public certificate.

4

Display challenge UI

Displays challenge UI showing Alice's name, trust level, and verification request.

5

Approve or deny

Bob approves/denies the verification request.

6

Encrypt response

Response is encrypted with Alice's device public key.

7

Sign and send response

Signed with Bob's device key and sent back to Alice.

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 result

Cryptographic 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 transmission

Challenge 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 integrity

ECDSA 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 challenge

Bob'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 device

Security Guarantees

1. 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

1. Hardware-Backed Authentication

• All signatures from Secure Enclave/StrongBox/TPM

• Private keys never leave hardware security modules

• Device attestation tokens verify hardware security level

1. Replay Attack Protection

• Cryptographic nonce in each challenge (unique)

• Challenge expiration (10-minute TTL in Redis)

• Timestamp validation prevents old challenges

1. Man-in-the-Middle Protection

• Mutual certificate verification required

• PKI trust chain: Device → Master → Root CA

• Signature validation before showing challenge UI

1. 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 validated

Document Version: 1.0 Last Updated: 2025-10-10 SDK Version: gettrusted-sdk-dual v2.0 API Version: gettrusted-api v1.0