What`s Paddle?

Paddle is a 2FA device for decentralized wallet connectivity, allowing an extra layer of physical security for your tokenized assets (in beta)

1. Introduction

Blockchain technology has brought decentralization and increased security to digital systems, particularly in the finance sector. However, authenticating users' identity for transactions remains a challenge. Paddle addresses this by introducing a zk-STARK-based biometric authentication system that is both secure and user-friendly.

2. Background and Motivation

Traditional methods of authentication, such as passwords and PINs, are vulnerable to brute force and phishing attacks. Moreover, passwords and pincodes only store the knowledge of them, and not the real identity of a person. Storing sensitive data like biometric information on-chain is risky due to potential data breaches and current methods only rely on passwords and hackable devices. Paddle overcomes these limitations by using zk-STARK proofs together with its own biometric authentification device. This allows 2FA authentification on a completely new level, without revealing or storing any sensitive information. This makes it post-quantum proof and nearly impossible to hack. Let's change the world of digital identity forever.

3. System Architecture

3.1 Paddle Device

The Paddle device is a handheld unit that includes a fingerprint scanner, Hardware Security Module (HSM), microcontroller, and other components necessary for functioning. It connects to a user's wallet and the blockchain contract for transaction authentication.

3.1.1 Device Components

Fingerprint Scanner: Captures the biometric data of the user.
Hardware Security Module (HSM): Securely stores cryptographic keys and biometric data. Used for zk-STARK proof generation.
Microcontroller: Manages primary operations and controls other components.
Display: Provides feedback and instructions to the user.
Buttons: Used for user input and navigation.
Bluetooth Chip: Facilitates communication with the blockchain contract / the device with the wallet.
Power Source: Supplies power to the device.
Storage: Stores essential data and system firmware.
NFT-Chip: Supports contactless payments.

3.1.2 Firmware Functions

init_device(): Initializes the device, loads drivers, and establishes a secure connection with the blockchain contract.
authenticate_user(fingerprint_data): Validates the user's fingerprint against the stored hash.
generate_proof(fingerprint_hash): Creates a zk-STARK proof of the fingerprint hash.
transmit_proof(proof): Sends the encrypted proof to the blockchain contract.
verify_proof(contract_address, proof): Awaits verification from the contract.
protect_device(): Implements physical and software security measures.
secure_storage(data, action): Manages data storage securely.

3.2 Blockchain Contract

The blockchain contract resides on the OpenLoan blockchain and manages biometric proof requests. It is programmed to initiate a request when a transaction is triggered and embeds the zk-STARK verification functions.

3.2.1 Contract Functions

request_proof(user_address): Sends a proof request to the user's Paddle device.
receive_proof(user_address, proof): Receives the encrypted proof from the device.
verify_proof(proof): Verifies the proof against the stored hash.
execute_transaction(user_address, proof_status): Carries out the transaction if the verification is successful.

4. zk-STARKs

4.1 Basic Principles

zk-STARKs (Zero-Knowledge Scalable Transparent ARguments of Knowledge) are cryptographic proofs that enable one party to prove to another party that a statement is true without revealing any information other than the statement's truth. zk-STARKs are considered highly secure and are resistant to quantum attacks.

4.2 zk-STARK Proof Generation

The zk-STARK proof generation process is carried out by the prover, in this case, the Paddle device. It involves the creation of a proof π that attests to the knowledge of the fingerprint hash, without revealing it.

4.2.1 Mathematical Foundations of zk-STARK Proof Generation

The foundation of zk-STARK proof generation lies in algebraic commitment schemes, polynomial IOP (Interactive Oracle Proofs), and the Fast Fourier Transform over finite fields.

Polynomial Commitment: Given a polynomial $P(x)$ of degree $d$ , and a point $s$ in the finite field, the Paddle device constructs $P(x)$ using the hash of the fingerprint as one of the coefficients. This polynomial is then evaluated at point $s$ , which is kept secret.
Commitment Scheme: Using Merkle trees, the device commits to the polynomial and sends a commitment to the blockchain contract. The commitment acts as a binding agreement to the polynomial without revealing its details.
Aryeh's Protocol: Leveraging on the work of Professor Eli Ben-Sasson, the proof generation uses Aryeh’s protocol, which is an Interactive Oracle Proof. The Paddle device interacts with the oracle to produce a proof π of the fingerprint's hash.

4.2.2 Example Code for zk-STARK Proof Generation

from zkstarklib import PolynomialCommitment, AryehProtocol

def generate_proof(fingerprint_hash):
    # Create a polynomial with the fingerprint hash
    poly = PolynomialCommitment.create_polynomial(fingerprint_hash)
    
    # Commit to the polynomial
    commitment = PolynomialCommitment.commit(poly)
    
    # Interact with the Aryeh Protocol to produce a proof
    protocol = AryehProtocol(poly, commitment)
    proof = protocol.generate_proof()
    
    return proof

4.3 zk-STARK Verification

The verification of zk-STARKs proofs is relatively more straightforward and efficient than their generation. It involves the use of the commitment and the proof to validate the authenticity of the data.

4.3.1 Steps Involved in zk-STARK Verification:

Commitment Validation: The blockchain contract checks the received commitment to ensure it corresponds to the polynomial claimed by the device.
Interactive Proof Verification: The contract interacts with the oracle in the Aryeh's Protocol to validate the proof π.
Verification Outcome: If both the commitment and proof π are valid, the blockchain contract considers the authentication successful. If either fails, the authentication process is terminated.

4.3.2 Example Code for zk-STARK Verification

pragma solidity ^0.6.0;

import "zkstarklib.sol";

contract ZKSTARKVerifier {
    function verify_proof(bytes memory proof, bytes memory commitment) public view returns (bool) {
        // Validate commitment
        bool commitment_valid = zkstarklib.validate_commitment(commitment);
        if (!commitment_valid) {
            return false;
        }

        // Interact with the Aryeh Protocol to verify proof
        bool proof_valid = zkstarklib.verify_proof(proof, commitment);
        if (!proof_valid) {
            return false;
        }

        // Both commitment and proof are valid
        return true;
    }
}

5. Authentication Protocol

5.1 Initial Setup

In the initial setup phase, the user registers their fingerprint with the Paddle device, and the device computes the fingerprint hash, securely storing it in the HSM. The Paddle device also establishes a secure communication channel with the blockchain contract for future transactions.

def init_device():
    # Load drivers
    load_drivers()

    # Establish a secure connection with the blockchain contract
    establish_secure_connection()

    # Register user's fingerprint
    fingerprint_data = register_fingerprint()

    # Compute the fingerprint hash
    fingerprint_hash = compute_hash(fingerprint_data)

    # Securely store the fingerprint hash in the HSM
    secure_storage(fingerprint_hash, "write")

    return True

5.2 Fingerprint Authentication

The user places their finger on the Paddle device's scanner for authentication. The device captures the fingerprint, computes the hash, and compares it with the previously stored hash. If the hashes match, the authentication proceeds to the next step; otherwise, it is terminated.

def authenticate_user(fingerprint_data):
    # Compute the fingerprint hash
    fingerprint_hash = compute_hash(fingerprint_data)

    # Retrieve the stored hash from HSM
    stored_hash = secure_storage(fingerprint_hash, "read")

    # Validate the fingerprint hash against the stored hash
    if fingerprint_hash == stored_hash:
        return True
    else:
        return False

5.3 Proof Transmission and Verification

After successful fingerprint authentication, the Paddle device generates a zk-STARK proof and encrypts it for secure transmission to the blockchain contract. The contract decrypts the proof, verifies it, and, if successful, executes the transaction.

def transmit_proof(proof):
    # Encrypt the proof
    encrypted_proof = encrypt(proof)

    # Transmit the encrypted proof to the blockchain contract
    contract_address = get_contract_address()
    blockchain_contract.receive_proof(contract_address, encrypted_proof)

def verify_proof(contract_address, proof):
    # Decrypt the proof
    decrypted_proof = decrypt(proof)

    # Verify the proof
    proof_status = ZKSTARKVerifier.verify_proof(decrypted_proof, commitment)

    return proof_status

5.4 Communication Between Device and Contract

5.4.1 Establishing a Secure Channel

When the Paddle device is initialized for the first time, it generates a public-private key pair and establishes a secure connection with the blockchain contract. This connection is established using Transport Layer Security (TLS) to ensure data confidentiality, integrity, and authentication.

def establish_secure_connection():
    # Generate public-private key pair
    public_key, private_key = generate_key_pair()

    # Transmit public key to the blockchain contract
    contract_address = get_contract_address()
    blockchain_contract.receive_public_key(contract_address, public_key)

    # Establish a secure TLS connection
    tls_connection = establish_tls(contract_address, public_key)

    return tls_connection

5.4.2 Proof Transmission

Once the zk-STARK proof has been generated by the Paddle device, it needs to be securely transmitted to the blockchain contract. The proof is encrypted using the contract's public key and sent through the secure TLS connection.

def transmit_proof(proof):
    # Encrypt the proof with the contract's public key
    encrypted_proof = asymmetric_encrypt(proof, contract_public_key)

    # Transmit the encrypted proof through the secure TLS connection
    tls_connection.send(encrypted_proof)

    return True

5.4.3 Proof Reception and Verification

Upon receiving the encrypted proof, the blockchain contract decrypts it using its private key. Then, it verifies the proof using the stored hash. If the proof is valid, the contract executes the transaction.

function receive_proof(address user_address, bytes memory encrypted_proof) public returns (bool) {
    // Decrypt the proof with the contract's private key
    bytes memory decrypted_proof = asymmetric_decrypt(encrypted_proof, private_key);

    // Verify the proof
    bool proof_valid = zkstarklib.verify_proof(decrypted_proof, commitment);

    if (proof_valid) {
        // Execute the transaction
        execute_transaction(user_address, true);
    }

    return proof_valid;
}

5.4.4 Proof Feedback

After verifying the proof, the blockchain contract sends feedback to the Paddle device, indicating whether the proof was accepted or rejected. This feedback is encrypted with the device's public key and sent through the secure TLS connection.

function send_feedback(address user_address, bool proof_status) public returns (bool) {
    // Encrypt the feedback with the device's public key
    bytes memory encrypted_feedback = asymmetric_encrypt(proof_status, device_public_key);

    // Send the encrypted feedback through the secure TLS connection
    tls_connection.send(encrypted_feedback);

    return true;
}

5.4.5 Closing the Connection

Once the proof transmission, verification, and feedback processes are complete, the secure TLS connection is terminated. This ensures that the communication channel is only active during the authentication process, minimizing the risk of unauthorized access.

def close_connection():
    # Close the secure TLS connection
    tls_connection.close()

    return True

5.5 Application Process and Setup

5.5.1 Initial Application

To start using the Paddle biometric authentication system, users must first complete an initial application process. During this process, the user will register their Paddle device, set up a PIN, and provide their biometric data (fingerprint) for proof generation.

def apply():
    # Register the Paddle device
    device_id = register_device()

    # Set up a PIN
    pin = set_up_pin()

    # Provide fingerprint data for proof setup
    fingerprint_hash = fingerprint_proof_setup()

    # Set up a secure contract connection
    secure_connection = secure_contract_connection_setup()

    return device_id, pin, fingerprint_hash, secure_connection

5.5.2 PIN Setup

The user will be prompted to set up a PIN on their Paddle device. This PIN will be required each time they wish to authenticate a transaction, ensuring an additional layer of security.

def set_up_pin():
    # Prompt user to enter a PIN
    pin = input("Enter a 4-digit PIN: ")

    # Verify that the PIN is valid (4 digits)
    if len(pin) != 4 or not pin.isdigit():
        raise ValueError("Invalid PIN. Please enter a 4-digit PIN.")

    # Hash the PIN for secure storage
    hashed_pin = hash_pin(pin)

    # Store the hashed PIN on the device
    store_hashed_pin(hashed_pin)

    return hashed_pin

5.5.3 Fingerprint Proof Setup

The user will provide their fingerprint data, which will be used for generating zk-STARK proofs. This data will be securely stored as a hash on the device.

def fingerprint_proof_setup():
    # Capture the user's fingerprint data
    fingerprint_data = capture_fingerprint()

    # Hash the fingerprint data for secure storage
    fingerprint_hash = hash_fingerprint(fingerprint_data)

    # Store the hashed fingerprint on the device
    store_hashed_fingerprint(fingerprint_hash)

    return fingerprint_hash

5.5.4 Secure Contract Connection Setup

The Paddle device will establish a secure connection with the blockchain contract for proof transmission and verification. This connection will be secured using the device's and contract's public-private key pairs.

def secure_contract_connection_setup():
    # Generate a public-private key pair for the device
    device_public_key, device_private_key = generate_key_pair()

    # Transmit the device's public key to the contract
    contract_address = get_contract_address()
    blockchain_contract.receive_public_key(contract_address, device_public_key)

    # Establish a secure TLS connection
    secure_connection = establish_secure_connection()

    return secure_connection

8. Device Components and Interaction

In this section, we delve deeper into the individual components required for the Paddle device, their programming, and how they interact together. We also identify additional devices necessary for the system's functioning.

Bluetooth Communication in the Paddle Device

Introduction

Bluetooth is a wireless communication technology that allows data transmission between devices over short distances using radio waves. It operates on the Industrial, Scientific, and Medical (ISM) 2.4 GHz radio frequency band. The Paddle device uses a Bluetooth chip to establish a secure communication channel with the user's smartphone or computer, which in turn connects to the blockchain contract.

Bluetooth Chip Technical Specifications

The Bluetooth chip in the Paddle device is compliant with Bluetooth Low Energy (BLE) standards. BLE is optimized for low power consumption and is suitable for applications where data needs to be transmitted intermittently.

Frequency Band: 2.4 GHz ISM band
Modulation: Gaussian Frequency Shift Keying (GFSK)
Data Rate: 1 Mbps
Range: Up to 2 meters

Communication Process

Pairing: When the Paddle device is powered on, it enters pairing mode. The user's smartphone or computer detects the Paddle device and establishes a secure connection by exchanging encryption keys.
Authentication: After pairing, the Paddle device sends a one-time challenge to the user's smartphone or computer. The user enters their PIN on the smartphone or computer, and the device responds with a hashed version of the PIN. The Paddle device verifies the response.
Data Transmission: Once authenticated, the Paddle device sends the zk-STARK proof to the user's smartphone or computer, which forwards it to the blockchain contract.

Bluetooth Protocol Stack

The Bluetooth protocol stack consists of multiple layers that handle different aspects of the communication process. The Paddle device implements the following layers:

Application Layer: Contains the device's firmware and application code.
Logical Link Control and Adaptation Protocol (L2CAP): Segments and reassembles data packets.
Host Controller Interface (HCI): Provides an interface between the host and the Bluetooth controller.
Link Manager Protocol (LMP): Manages link setup, authentication, and encryption.
Baseband Layer: Handles physical radio connections.

Code Example

Here's a simplified Python code example for the Paddle device's firmware, demonstrating how to initiate a Bluetooth connection, authenticate, and send data to a paired smartphone or computer:

import bluetooth

# Initialize Bluetooth socket
server_sock = bluetooth.BluetoothSocket(bluetooth.RFCOMM)
server_sock.bind(("", bluetooth.PORT_ANY))
server_sock.listen(1)

print("Waiting for connection...")
client_sock, address = server_sock.accept()
print(f"Connected to {address}")

# Authentication
challenge = generate_challenge()
client_sock.send(challenge)
response = client_sock.recv(1024)
if verify_response(response):
    print("Authentication successful")
else:
    print("Authentication failed")
    client_sock.close()
    server_sock.close()
    exit()

# Send zk-STARK proof
proof = generate_zk_stark_proof()
client_sock.send(proof)
print("Proof sent")

# Close sockets
client_sock.close()
server_sock.close()

Bluetooth Security

The Paddle device uses Secure Simple Pairing (SSP) to establish a secure connection. SSP provides protection against eavesdropping and man-in-the-middle attacks by using Elliptic Curve Diffie-Hellman (ECDH) key exchange.

Conclusion

The Bluetooth chip in the Paddle device provides a secure and efficient means of communication with the user's smartphone or computer. The device uses robust authentication and encryption methods to ensure data security during transmission.

6. Security Considerations

6.1 Device Security

To ensure the physical security of the Paddle device, it is equipped with tamper-proofing mechanisms that prevent unauthorized access to the hardware components and the stored data. Additionally, the HSM is designed to resist physical attacks that aim to retrieve cryptographic keys or other sensitive information.

6.2 Side-Channel Attacks

The Paddle device implements countermeasures against side-channel attacks, which can exploit information leaked from the physical device, such as power consumption or electromagnetic radiation. Techniques like constant-time execution and power analysis resistance are employed to mitigate these attacks.

6.3 Software and Firmware Security

The Paddle device's firmware is regularly updated with security patches and improvements. Secure boot mechanisms and code signing are used to ensure that only authorized and verified firmware runs on the device. Additionally, the device's software stack is hardened against buffer overflow and other common software vulnerabilities.

7. Optimizations and Future Directions

Future optimizations to the Paddle system include the integration of additional biometric modalities, such as facial and voice recognition, for enhanced security. Moreover, the system aims to leverage advancements in post-quantum cryptography to remain secure against future threats.

8.1 Hardware Components

8.1.1 Fingerprint Scanner

Component: Fingerprint Scanner Function: Capture the user's fingerprint data for biometric verification Selection Criteria: High-resolution image capture, low false acceptance rate, and false rejection rate

8.1.2 Hardware Security Module (HSM)

Component: NXP A71CH HSM Function: Safeguard sensitive data and cryptographic keys, generate zk-STARK proofs Selection Criteria: Tamper-resistance, secure key storage, robust cryptographic operations

8.1.3 Microcontroller

Component: ARM-Cortex Microcontroller Function: Manage primary operations, control other components, execute firmware Selection Criteria: Efficient power usage, secure boot capabilities, GPIO availability

8.1.4 Display

Component: 2x2 cm LCD Function: Display information, feedback, instructions Selection Criteria: High visibility, low power consumption, small form factor

8.1.5 Buttons

Component: Three tactile buttons (Left, Right, Center) Function: User input, device navigation Selection Criteria: Reliable tactile feedback, durability

8.1.6 Bluetooth Chip

Component: Function: Communication with the blockchain contract Selection Criteria: Low power consumption, reliable connectivity, secure communication

8.1.7 Power Source

Component: Lithium-polymer battery and power management IC Function: Power supply for the device Selection Criteria: High energy density, rechargeability, stability, efficient power management

8.1.8 Storage

Component: AT25XE021A Secure Storage Chip Function: Store essential data, firmware, cryptographic keys Selection Criteria: Secure storage, high reliability, data integrity

8.1.9 Enclosure

Component: Protective Enclosure Function: Protect and encapsulate all components Selection Criteria: Durability, ergonomics, ease of access for maintenance

8.1.10 Additional Devices

Component: USB Interface Function: Device charging, firmware updates, secure connection to external systems Selection Criteria: Data transfer rate, secure connection, compatibility

Component: Real-Time Clock (RTC) Function: Timekeeping, transaction timestamps, device synchronization Selection Criteria: Accuracy, low power consumption, backup battery support

8.2 Component Interaction and Programming

Initialization: The ARM-Cortex microcontroller initializes all components, loads the drivers, establishes a secure connection with the blockchain contract, and sets up the real-time clock.

void init_device() {
    // Initialize HSM, Display, Buttons, WiFi, Storage
    init_hsm();
    init_display();
    init_buttons();
    init_wifi();
    init_storage();

    // Establish secure connection with blockchain contract
    establish_connection();

    // Set up the real-time clock
    setup_rtc();
}

User Authentication: The microcontroller directs the fingerprint scanner to capture the user's biometric data, sends it to the HSM for hash generation, and generates a zk-STARK proof using the hash.

void authenticate_user() {
    // Capture fingerprint data
    fingerprint_data = capture_fingerprint();

    // Generate fingerprint hash in HSM
    fingerprint_hash = generate_hash(fingerprint_data);

    // Generate zk-STARK proof
    proof = generate_proof(fingerprint_hash);

    // Transmit proof to blockchain contract
    transmit_proof(proof);
}

Communication: The microcontroller uses the ESP32 WiFi chip to transmit the zk-STARK proof to the blockchain contract and await verification. It ensures secure and encrypted communication using TLS.

void transmit_proof(proof) {
    // Establish secure TLS connection
    establish_tls_connection();

    // Send proof to blockchain contract
    send_data(proof);

    // Await verification result
    verification_result = receive_verification();

    // Display result on OLED/LCD
    display_result(verification_result);
}

Device Protection: The microcontroller enables tamper detection mechanisms in the HSM and protective features in the secure storage chip to guard against physical and software attacks.

void protect_device() {
    // Enable tamper detection in HSM
    enable_tamper_detection();

    // Protect secure storage
    secure_storage_protection();
}

User Input and Display: The microcontroller uses tactile buttons for user input and navigation and displays information on the OLED or LCD.

void handle_input() {
    // Read button input
    button_pressed = read_buttons();

    // Execute corresponding action
    execute_action(button_pressed);
}

The microcontroller coordinates the interactions between all components and executes firmware functions, ensuring efficient and secure operation of the Paddle device.

9. NFT Chip Integration

9.1 Overview

The inclusion of an NFT (Near-Field Communication) chip in the Paddle device enhances its functionality and enables contactless payment transactions directly from the user's blockchain wallet. The integration of an NFT chip makes it possible for users to make payments by simply bringing their Paddle device in proximity to a compatible NFT reader without the need for any physical contact.

9.2 NFT Chip Components

The NFT chip comprises several components essential for enabling secure and seamless contactless transactions. These components include:

Antenna Coil: The antenna coil is responsible for generating an electromagnetic field that can communicate with an NFT reader.
Capacitors: Capacitors are connected to the antenna coil to form an LC circuit, allowing the NFT chip to tune to the required frequency.
Modulator/Demodulator: The modulator encodes the digital signal for transmission, and the demodulator decodes the received signals from the NFT reader.
Microcontroller: The microcontroller manages the NFT chip's operations, processes transaction requests, and communicates with the main Paddle microcontroller.
Security Elements: Secure elements store cryptographic keys used for transaction authorization and provide hardware-based security for the NFT chip.

9.3 NFT Chip Communication

The NFT chip's communication occurs in two primary phases: proximity detection and data exchange.

Proximity Detection: When the Paddle device comes near an NFT reader, the antenna coil in the NFT chip detects the electromagnetic field generated by the reader and establishes communication.
Data Exchange: Once the connection is established, the NFT chip and reader engage in data exchange using modulated signals. The reader sends a request for payment information, and the NFT chip responds with the necessary data, encrypted using keys stored in the security elements.

9.4 Transaction Authentication

When the user initiates a contactless payment, the Paddle device captures their fingerprint and verifies it against the stored hash. The Hardware Security Module (HSM) generates a zk-STARK proof of the fingerprint hash, which is sent to the blockchain contract for verification. Upon successful verification, the blockchain contract authorizes the NFT chip to proceed with the transaction.

void nft_payment() {
    // Capture and authenticate fingerprint
    authenticate_user();

    // Request and verify zk-STARK proof
    request_proof();
    verify_proof();

    // Execute NFT transaction
    execute_nft_transaction();
}

9.5 NFT Transaction Execution

Once authorized, the NFT chip's microcontroller processes the payment request, accesses the user's blockchain wallet, and transfers the specified amount to the recipient's address. The transaction is secured using cryptographic keys stored in the security elements.

void execute_nft_transaction() {
    // Access user's blockchain wallet
    access_wallet();

    // Transfer funds to recipient
    transfer_funds();

    // Confirm transaction
    confirm_transaction();
}

9.6 Security Considerations

The integration of the NFT chip adds a new dimension to the security of the Paddle device. The NFT chip's security elements store cryptographic keys used for transaction authorization, and the chip communicates with the main Paddle microcontroller to verify the user's identity through fingerprint authentication. This multi-layered security approach ensures that contactless payments are secure and only authorized by the verified user.

PreviousWallet Freeze Mechanism NextPrototype

Last updated 5 months ago