Skip to content

Card Security

UniVoucher's security model uses advanced cryptography to ensure that only the intended recipient can redeem a gift card. This page explains the technical details of the security mechanisms.

Security Overview

UniVoucher uses a combination of asymmetric cryptography, key encryption, and zero-knowledge proofs to create a secure tangible gifting mechanism that doesn't require pre-registration of recipients.

Cryptographic Model

Key Components

Each UniVoucher tangible gift card includes these cryptographic components:

  1. Key Pair: A unique Ethereum key pair (public and private key)
  2. Slot ID: The public key, used as the card's on-chain identifier
  3. User-Friendly Secret: A 20-character redemption code (format: XXXXX-XXXXX-XXXXX-XXXXX)
  4. Encrypted Private Key: The card's private key, encrypted with the user-friendly secret

Security Flow

The security model follows this flow:

  1. Generate a random Ethereum key pair
  2. Generate a user-friendly secret with sufficient entropy
  3. Encrypt the private key using the secret
  4. Store the encrypted private key and public key on the blockchain
  5. Share the card ID and secret with the recipient (off-chain)
  1. Recipient enters the card ID and secret
  2. System retrieves the encrypted private key from the blockchain
  3. System decrypts the private key using the provided secret
  4. System creates a cryptographic signature with the decrypted private key
  5. Smart contract verifies the signature against the stored public key
  6. If verified, funds are transferred to the recipient's address

Encryption Details

Secret Generation

The user-friendly secret is generated with these characteristics:

  • Format: XXXXX-XXXXX-XXXXX-XXXXX (20 letters, 23 characters including hyphens)
  • Character set: Uppercase English alphabet (A-Z)
  • Entropy: At least 70 bits of entropy, providing sufficient security
  • Generation method: Cryptographically secure random generation

Example Secret

FKTML-XNPRQ-ZASEV-BGUCH

Private Key Encryption

Private keys are encrypted using:

  1. Key Derivation: PBKDF2 with these parameters:
  2. Salt: 16 random bytes unique to each encryption
  3. Iterations: 310,000 rounds
  4. Hash function: SHA-256

  5. Output key size: 256 bits

  6. Encryption Algorithm: AES-GCM with these parameters:

  7. Key: The derived key from step 1
  8. IV: 12 random bytes unique to each encryption

  9. Authentication tag: Included to verify decryption integrity

  10. Storage Format: JSON with these fields: 

    {
  "salt": "hex_encoded_salt",
  "iv": "hex_encoded_initialization_vector",
  "ciphertext": "base64_encoded_encrypted_private_key"
}

Signature Verification

During redemption, the contract uses a signature verification process:

sequenceDiagram
    participant User
    participant Frontend
    participant Contract

    User->>Frontend: Enter Card ID & Secret
    Frontend->>Contract: Query Card Data
    Contract-->>Frontend: Return Encrypted Private Key
    Frontend->>Frontend: Decrypt Private Key using Secret
    Frontend->>Frontend: Sign Message with Private Key
    Frontend->>Contract: Submit Signature & Destination Address
    Contract->>Contract: Verify Signature
    Contract-->>User: Transfer Funds
  1. The decrypted private key signs a specific message containing:
  2. A prefix: "Redeem card:"
  3. The card ID: Unique identifier
  4. A destination prefix: "to:"

  5. The recipient address: Where funds will be sent

  6. The smart contract:

  7. Constructs the same message
  8. Recovers the signer address from the provided signature
  9. Verifies that the recovered address matches the card's slot ID (public key)
  10. If verified, proceeds with the transfer

This proves that the redeemer knows the private key (via the secret) without revealing it.

Security Guarantees

Security Guarantees

This security model provides several guarantees:

  1. Secret Confidentiality: The card secret is never stored on-chain
  2. Zero Knowledge: The redemption proves knowledge of the secret without revealing it
  3. Non-Transferability: The signature is bound to a specific recipient address
  4. Tamper Resistance: Any change to the encrypted data would prevent successful decryption
  5. Brute Force Protection: The PBKDF2 key derivation is computationally expensive to brute force

Client-Side Security

The client-side application includes additional security features:

  1. Secure Key Handling:
  2. Private keys are only ever held in memory temporarily
  3. Keys are never sent to any server

  4. All cryptographic operations happen in the user's browser

  5. Secret Input Handling:

  6. Automatic formatting of secrets for better readability
  7. Case-insensitive handling

  8. Validation before submission

  9. Distribution Security:

  10. Generated cards are available for immediate download
  11. Cards can be downloaded as plain text or CSV files
  12. Clear instructions encourage secure distribution of secrets

Security Considerations

Security Considerations

While the cryptographic model is robust, users should be aware of these considerations:

  1. Secret Distribution: The security depends on the secret being shared securely
  2. Secret Storage: Recipients should store the secret securely until redemption
  3. Front-End Security: Users should always verify they're on the authentic UniVoucher website
  4. Phishing Risk: Attackers might create fake interfaces to steal card secrets

Smart Contract Security

The smart contract includes security features to prevent common attacks:

Feature Description
Reentrancy Protection Functions that modify state are protected against reentrancy
Access Controls Only card creators can cancel their cards
Signature Replay Prevention Each signature can only be used once
Input Validation All inputs are validated before processing

Cancellation Security

Card cancellation requires:

  1. The transaction sender must be the original card creator
  2. The card must still be active (not redeemed)
  3. A signed transaction from the creator's wallet

Abandonment Protection

Abandonment Protection

To prevent permanent fund loss:

  1. Cards include a 5-year abandonment period
  2. After this period, the contract owner can intervene
  3. This appears as an "Abandoned On" date in the card details
  4. In normal circumstances, creators can cancel cards at any time

Security Recommendations

For maximum security, we recommend:

  1. Share card IDs and secrets through separate secure channels
  2. Use temporary/expiring messaging when possible
  3. Verify with recipients when they've successfully redeemed
  4. Cancel cards promptly if they're compromised or no longer needed
  5. Use a hardware wallet for creating high-value cards

Best Practice

When sending a gift card, consider sending the card ID and secret through different communication channels. For example, send the card ID via email and the secret via a messaging app.