Streaming Decryption Engine

This project implemented a comprehensive hardware abstraction of a streaming decryption engine on STM32F042K6 boards, capable of receiving and decrypting data encrypted with XOR, DES, or AES-128 protocols. The engine stored decryption keys within its firmware and was designed to handle standardized encrypted data streams. After implementation and testing, the systems were distributed to other teams for security analysis using reverse engineering techniques and side-channel attacks, demonstrating real-world hardware security vulnerabilities and mitigation strategies.

In ECE-GY 9453 (Hardware Security), our team developed a streaming decryption engine that received encrypted data streams, analyzed the encryption protocol (None, XOR, DES, or AES-128), and performed decryption using embedded keys. The project culminated in a comprehensive security analysis where teams reverse-engineered each other’s implementations using Ghidra decompilation and performed Correlation Power Analysis (CPA) attacks using ChipWhisperer tools, revealing critical vulnerabilities in embedded cryptographic systems.

Table of Contents

1. Project Overview
2. Technical Architecture
   • Streaming Engine Design
   • Cryptographic Implementation
   • Security Analysis Framework
3. Security Analysis Methodology
   • Reverse Engineering with Ghidra
   • Power Analysis with ChipWhisperer
   • Threat Model Assessment
4. Technical Implementation Details
   • Protocol Detection System
   • Key Management Architecture
   • Blocking Mechanism
5. Attack Results and Analysis
   • Reverse Engineering Results
   • Power Analysis Results
   • Vulnerability Assessment
6. Security Mitigation Strategies
   • AMASIVE Framework Integration
   • Random Dynamic Frequency Scaling
   • Key Management Improvements
7. Learning Outcomes
8. Project Impact

Project Overview

Primary Objectives:

1. Streaming Decryption Engine: Implement a hardware abstraction capable of detecting and decrypting XOR, DES, and AES-128 encrypted data streams
2. Security Analysis: Conduct comprehensive reverse engineering and side-channel attacks on peer implementations
3. Vulnerability Assessment: Identify and document realistic threats and practical defense mechanisms
4. Mitigation Strategy Development: Research and propose advanced security countermeasures for embedded cryptographic systems

Key Innovation: This project extended beyond typical cryptographic implementation by incorporating real-world security analysis techniques, including firmware reverse engineering and correlation power analysis, providing hands-on experience with both attack and defense methodologies in hardware security.

Technical Architecture

Streaming Engine Design

The streaming decryption engine was implemented on STM32F042K6 microcontrollers with the following key components:

• Protocol Detection: Analyzed incoming data streams to identify encryption protocol (None, XOR, DES, or AES-128)
• Key Management: Embedded decryption keys within firmware for XOR, DES, and AES-128 protocols
• Blocking Mechanism: Implemented input buffering to prevent overflow and ensure data integrity
• Success Reporting: Provided status feedback on decryption success and protocol validity

System Architecture:

• Input Buffer: Configurable buffer size for incoming encrypted data
• Protocol Byte Processing: First byte analysis to determine encryption type
• Decryption Pipeline: Multi-protocol decryption engine with embedded keys
• Output Management: Decrypted data transmission with success status reporting

Cryptographic Implementation

The engine supported three distinct cryptographic protocols:

XOR Encryption:

• Implementation: Simple bitwise XOR operation between data and key
• Key Storage: 16-byte keys embedded in firmware
• Protocol Byte: 0x20 identifier for XOR-encrypted data

DES Encryption:

• Implementation: Standard DES algorithm with 8-byte keys
• Key Storage: Embedded DES keys in firmware memory
• Protocol Byte: 0x30 identifier for DES-encrypted data

AES-128 Encryption:

• Implementation: AES-128 algorithm with 16-byte keys
• Key Storage: Embedded AES keys in firmware memory
• Protocol Byte: 0x40 identifier for AES-encrypted data

Security Analysis Framework

The project incorporated comprehensive security analysis methodologies:

• Reverse Engineering: Using Ghidra for firmware decompilation and key extraction
• Power Analysis: Correlation Power Analysis (CPA) attacks using ChipWhisperer
• Threat Modeling: Assessment of realistic attack vectors and vulnerabilities
• Mitigation Research: Analysis of advanced security countermeasures

Security Analysis Methodology

Reverse Engineering with Ghidra

Our reverse engineering approach focused on systematic key extraction using advanced decompilation techniques:

XOR Key Extraction Methods:

// Method 1: Locate XOR operations in decompiled code
// Search for patterns like: data[i] ^ key[i % 16]
// In Ghidra, look for XOR operations (^) in main function
// Key locations typically found in .data section

// Method 2: Pattern matching with known test vectors
// Given input: "test_data" and expected output: "decrypted_data"
// Calculate: key_byte = input_byte ^ output_byte
// Search memory for matching key pattern

// Example Ghidra analysis script:
void find_xor_keys() {
    // Search for XOR operations in main function
    Function main_func = getFunctionByName("main");
    InstructionIterator iter = main_func.getInstructionIterator();
    
    while(iter.hasNext()) {
        Instruction instr = iter.next();
        if(instr.getMnemonicString().equals("XOR")) {
            // Extract key address from operand
            Address key_addr = instr.getOpObjects(1)[0];
            // Extract 16-byte key from memory
            byte[] key = getBytes(key_addr, 16);
            printf("Found XOR key: %02X %02X %02X...\n", 
                   key[0], key[1], key[2]);
        }
    }
}

DES Key Extraction Methods:

// Method 1: Trace DES subkey generation
// DES uses 16 rounds with different subkeys
// Look for DES key schedule function calls
// Key typically stored as 8-byte array

// Method 2: Memory search after XOR key location
// Keys often stored sequentially in memory
// Search 8 bytes after XOR key location

// Example DES key extraction:
void extract_des_key(Address xor_key_addr) {
    // DES key follows XOR key in memory
    Address des_key_addr = xor_key_addr.add(16);
    byte[] des_key = getBytes(des_key_addr, 8);
    
    // Verify with known test vector
    if(verify_des_key(des_key, test_input, expected_output)) {
        printf("Valid DES key found: %02X %02X %02X...\n",
               des_key[0], des_key[1], des_key[2]);
    }
}

// DES key verification function
bool verify_des_key(byte* key, byte* input, byte* expected) {
    byte output[8];
    des_decrypt_block(input, output, key);
    return memcmp(output, expected, 8) == 0;
}

AES Key Extraction Methods:

// Method 1: Reverse engineering approach
// AES-128 uses 10 rounds with 16-byte key
// Look for AES key expansion function
// Key stored as 16-byte array

// Method 2: Correlation Power Analysis (CPA)
// Use ChipWhisperer for power analysis
// Target S-box operations in first round

// Example AES key extraction:
void extract_aes_key(Address des_key_addr) {
    // AES key follows DES key in memory
    Address aes_key_addr = des_key_addr.add(8);
    byte[] aes_key = getBytes(aes_key_addr, 16);
    
    // Verify with known test vector
    if(verify_aes_key(aes_key, test_input, expected_output)) {
        printf("Valid AES key found: %02X %02X %02X...\n",
               aes_key[0], aes_key[1], aes_key[2]);
    }
}

// CPA attack implementation
void cpa_attack_aes() {
    // Collect power traces for 50 random plaintexts
    for(int i = 0; i < 50; i++) {
        byte plaintext[16] = generate_random_plaintext();
        byte[] power_trace = capture_power_trace(plaintext);
        
        // Store plaintext and corresponding trace
        plaintexts[i] = plaintext;
        traces[i] = power_trace;
    }
    
    // Perform correlation analysis
    byte[] recovered_key = correlate_power_traces(plaintexts, traces);
    printf("Recovered AES key: %02X %02X %02X...\n",
           recovered_key[0], recovered_key[1], recovered_key[2]);
}

Memory Analysis Techniques:

// Pattern-based key discovery
void search_memory_patterns() {
    // Search for known key patterns
    byte xor_pattern[] = {0xB7, 0x29, 0xA1, 0x88};
    Address addr = search_memory(xor_pattern, 4);
    
    if(addr != null) {
        printf("Found XOR key at: %08X\n", addr);
        // Extract full 16-byte key
        byte[] full_key = getBytes(addr, 16);
    }
}

// Cross-reference with test vectors
void verify_with_test_vectors() {
    // Known input: "abc" -> expected output: "xyz"
    byte input[] = "abc";
    byte expected[] = "xyz";
    
    // Calculate first key byte: key[0] = input[0] ^ expected[0]
    byte first_key_byte = input[0] ^ expected[0];
    
    // Search memory for this pattern
    Address key_addr = search_memory(&first_key_byte, 1);
    if(key_addr != null) {
        printf("Potential key found at: %08X\n", key_addr);
    }
}

Power Analysis with ChipWhisperer

Correlation Power Analysis (CPA) implementation:

Setup Process:

• Target Selection: Binary files performing AES encryption (binary1-4.hex)
• Trace Collection: 50 random plaintexts with corresponding power traces
• Power Model: Hamming-Weight of S-box output
• Analysis Method: ChipWhisperer CPA attack module

Attack Parameters:

• Iterations: 50 random plaintext generations
• Protocol Integration: Insert protocol byte into plaintext during capture
• Correlation Analysis: Statistical correlation between power consumption and key hypotheses

Threat Model Assessment

Comprehensive threat analysis revealed:

Realistic Threats:

• Firmware Reverse Engineering: Most practical threat using Ghidra decompilation
• Key Extraction: Successful extraction of 4 XOR keys, 4 DES keys, and 4 AES keys
• Memory Analysis: Pattern-based key discovery in firmware memory

Non-Realistic Threats:

• Fault Injection Attacks: Limited by lack of source code access
• Scan Chain Attacks: Not applicable due to missing scan chain outputs

Technical Implementation Details

Protocol Detection System

The engine implemented sophisticated protocol detection with comprehensive error handling and validation:

// Protocol byte definitions and constants
#define PROTOCOL_NONE          0x00
#define PROTOCOL_XOR           0x20
#define PROTOCOL_DES           0x30
#define PROTOCOL_AES           0x40
#define BUFFER_SIZE            1024
#define MAX_KEY_SIZE           16
#define SUCCESS_BYTE          0x01
#define ERROR_BYTE            0x00

// Protocol detection with validation
uint8_t detect_protocol(uint8_t protocol_byte) {
    switch(protocol_byte) {
        case PROTOCOL_XOR: 
            return XOR_DECRYPT;
        case PROTOCOL_DES: 
            return DES_DECRYPT;
        case PROTOCOL_AES: 
            return AES_DECRYPT;
        case PROTOCOL_NONE:
            return NO_ENCRYPTION;
        default: 
            return INVALID_PROTOCOL;
    }
}

// Main decryption engine with blocking mechanism
void streaming_decryption_engine(void) {
    uint8_t input_buffer[BUFFER_SIZE];
    uint8_t output_buffer[BUFFER_SIZE];
    uint8_t protocol_byte;
    uint8_t success_status;
    uint16_t data_length;
    
    while(1) {
        // Wait for protocol byte
        if(UART_ReceiveData(&protocol_byte, 1) == UART_OK) {
            uint8_t protocol_type = detect_protocol(protocol_byte);
            
            if(protocol_type == INVALID_PROTOCOL) {
                UART_TransmitData(&ERROR_BYTE, 1);
                continue;
            }
            
            // Receive data length
            UART_ReceiveData((uint8_t*)&data_length, 2);
            
            // Blocking mechanism: ignore excess data
            if(data_length > BUFFER_SIZE) {
                data_length = BUFFER_SIZE;
            }
            
            // Receive encrypted data
            if(UART_ReceiveData(input_buffer, data_length) == UART_OK) {
                // Perform decryption based on protocol
                success_status = perform_decryption(protocol_type, 
                                                 input_buffer, 
                                                 output_buffer, 
                                                 data_length);
                
                // Send success status
                UART_TransmitData(&success_status, 1);
                
                if(success_status == SUCCESS_BYTE) {
                    // Transmit decrypted data
                    UART_TransmitData(output_buffer, data_length);
                }
            }
        }
    }
}

// XOR decryption implementation
uint8_t xor_decrypt(uint8_t* input, uint8_t* output, uint16_t length) {
    static const uint8_t xor_key[16] = {
        0xB7, 0x29, 0xA1, 0x88, 0xEB, 0x61, 0xA4, 0x28,
        0x81, 0x46, 0xFD, 0x90, 0x4E, 0xAA, 0x3D, 0x89
    };
    
    for(uint16_t i = 0; i < length; i++) {
        output[i] = input[i] ^ xor_key[i % 16];
    }
    return SUCCESS_BYTE;
}

// DES decryption implementation
uint8_t des_decrypt(uint8_t* input, uint8_t* output, uint16_t length) {
    static const uint8_t des_key[8] = {
        0xB3, 0x98, 0xCE, 0x3D, 0xF5, 0x5D, 0x07, 0x84
    };
    
    // Ensure data length is multiple of 8 (DES block size)
    if(length % 8 != 0) {
        return ERROR_BYTE;
    }
    
    // Process data in 8-byte blocks
    for(uint16_t i = 0; i < length; i += 8) {
        des_decrypt_block(&input[i], &output[i], des_key);
    }
    return SUCCESS_BYTE;
}

// AES-128 decryption implementation
uint8_t aes_decrypt(uint8_t* input, uint8_t* output, uint16_t length) {
    static const uint8_t aes_key[16] = {
        0xD0, 0x22, 0x19, 0x0B, 0x88, 0x63, 0x83, 0x8B,
        0x54, 0x34, 0x50, 0xB4, 0xED, 0xEC, 0x32, 0xD5
    };
    
    // Ensure data length is multiple of 16 (AES block size)
    if(length % 16 != 0) {
        return ERROR_BYTE;
    }
    
    // Process data in 16-byte blocks
    for(uint16_t i = 0; i < length; i += 16) {
        aes_decrypt_block(&input[i], &output[i], aes_key);
    }
    return SUCCESS_BYTE;
}

// Main decryption dispatcher
uint8_t perform_decryption(uint8_t protocol_type, 
                          uint8_t* input, 
                          uint8_t* output, 
                          uint16_t length) {
    switch(protocol_type) {
        case XOR_DECRYPT:
            return xor_decrypt(input, output, length);
        case DES_DECRYPT:
            return des_decrypt(input, output, length);
        case AES_DECRYPT:
            return aes_decrypt(input, output, length);
        case NO_ENCRYPTION:
            // Copy data without modification
            memcpy(output, input, length);
            return SUCCESS_BYTE;
        default:
            return ERROR_BYTE;
    }
}

Key Management Architecture

Embedded key storage with security considerations:

• XOR Keys: 16-byte keys stored in firmware memory
• DES Keys: 8-byte keys following XOR key locations
• AES Keys: 16-byte keys embedded in firmware
• Memory Layout: Sequential key storage for reverse engineering resistance

Blocking Mechanism

Input buffer protection system:

• Buffer Size Control: Configurable maximum input buffer size
• Overflow Prevention: Ignore excess data beyond buffer capacity
• Processing Blocking: Ignore additional data during decryption
• Data Integrity: Maintain input stream integrity during processing

Technical Diagrams and Architecture

Attack Results and Analysis

Reverse Engineering Results

Successful key extraction from peer implementations:

Power Analysis Results

CPA attack results on binary files:

Vulnerability Assessment

Key security vulnerabilities identified:

Critical Vulnerabilities:

• Hardcoded Keys: All implementations had keys embedded in firmware
• Predictable Memory Layout: Sequential key storage enabled pattern-based extraction
• Lack of Obfuscation: No code obfuscation to hinder reverse engineering
• Missing Side-Channel Protection: No countermeasures against power analysis

Attack Effectiveness:

• Reverse Engineering: 100% success rate in key extraction
• Power Analysis: Successful CPA attacks on AES implementations
• Memory Analysis: Pattern-based key discovery highly effective

Security Mitigation Strategies

AMASIVE Framework Integration

Research into advanced side-channel protection (see Figure 1 and Figure 3):

Framework Components:

• Register Switching: Random register allocation to obscure power patterns
• Component Masking: Masked cryptographic operations
• Non-linear Function Masking: Protected S-box implementations
• Data Path Masking: Masked data transmission paths

Effectiveness Results (see Figure 4):

• Unprotected Design: 35,000 traces to guess all subkeys
• Random Register Switching: 37,000 traces to guess all subkeys
• Masked Switching: 31,000 traces to guess 81% of subkeys
• Data Path Masking: 97,000 traces to guess 69% of subkeys
• Full AMASIVE Framework: 100,000 traces to guess only 13% of subkeys

Random Dynamic Frequency Scaling

Advanced frequency-based countermeasures (see Figure 5 and Figure 6):

Implementation Strategy:

• Mixed Mode Clock Managers (MMCM): Generate 219,000+ distinct frequencies
• Asynchronous Clock Distribution: Dynamic frequency variation for cryptographic accelerators
• Power Pattern Obfuscation: Unpredictable power consumption patterns

Effectiveness Results:

• Before RDFS: 70,000 traces sufficient for key extraction
• After RDFS: No subkeys recovered even with 5 million traces
• Improvement: Exponential increase in attack complexity

Key Management Improvements

Practical security enhancements:

Algorithmic Key Generation:

• Dynamic Key Generation: Generate keys at runtime using algorithms
• Random Function Integration: Add random function calls for obfuscation
• Dummy Key Insertion: Insert fake keys to confuse attackers

Memory Protection:

• Key Scattering: Distribute keys across different memory locations
• Encryption of Keys: Encrypt embedded keys using additional layers
• Runtime Key Loading: Load keys from secure external storage

Learning Outcomes

Technical Skills Developed:

• Firmware Reverse Engineering: Mastery of Ghidra for binary analysis
• Side-Channel Analysis: Hands-on experience with power analysis attacks
• Cryptographic Implementation: Practical implementation of XOR, DES, and AES
• Security Assessment: Comprehensive threat modeling and vulnerability analysis

Security Insights Gained:

• Real-World Attack Vectors: Understanding of practical hardware security threats
• Defense Strategy Development: Research into advanced security countermeasures
• Trade-off Analysis: Balancing security, performance, and implementation complexity
• Industry Standards: Familiarity with security frameworks and best practices

Research Methodology:

• Literature Survey: Analysis of cutting-edge hardware security research
• Experimental Validation: Empirical testing of attack and defense mechanisms
• Comparative Analysis: Evaluation of different security approaches
• Documentation: Comprehensive reporting of findings and recommendations

Project Impact

Educational Value:

• Hands-on Security Experience: Practical application of hardware security concepts
• Attack-Defense Balance: Understanding both offensive and defensive security
• Industry Relevance: Real-world security challenges and solutions
• Research Integration: Connection between academic research and practical implementation

Technical Contributions:

• Vulnerability Documentation: Comprehensive catalog of embedded system vulnerabilities
• Mitigation Strategy Research: Analysis of advanced security countermeasures
• Tool Proficiency: Mastery of industry-standard security analysis tools
• Framework Evaluation: Assessment of security frameworks for embedded systems

Future Implications:

• Security Best Practices: Development of guidelines for secure embedded systems
• Countermeasure Integration: Strategies for implementing advanced security measures
• Threat Evolution: Understanding of emerging hardware security threats
• Defense Innovation: Research into novel security protection mechanisms

This project was completed as part of ECE-GY 9453 (Hardware Security) at NYU Tandon School of Engineering.