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

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