Secure Firmware Validation Using EMV Chip Checksums
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Current firmware and software updates on electronic devices like dynamic transaction cards are insecure, as they can introduce malware and spyware, and existing checksum validation methods are vulnerable due to shared storage and calculation on the same device component, lacking robust security measures.
Innovation Solution
Implementing an EMV chip as a Trusted Platform Module (TPM) to securely store and calculate checksums, enabling secure firmware and software updates through a secure terminal connection, with validation and decryption processes to ensure integrity, using cryptographic keys and checksum comparisons.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Ease of operation
If standard over-the-air (OTA) updates are used for firmware updates, then update convenience is improved, but security is worsened due to potential introduction of malware and spyware
Solution Approach 1:
The patent introduces a secure element as an intermediary component that acts as a trusted mediator between the firmware update source and the device. This secure element independently validates firmware updates using stored cryptographic keys and checksums, preventing malware introduction while maintaining OTA update convenience. The secure element serves as a trusted intermediary that the processor can rely on for security-critical functions.
Solution Approach 2:
The patent segments the device into two distinct functional components: a processor for executing firmware and a separate secure element for storing cryptographic keys and validating firmware integrity. This segmentation isolates security-critical functions from the main processor, preventing compromise of the entire system if the processor firmware is compromised. The secure element operates independently to validate updates before they are executed.
2Device complexity
If checksum storage and validation occur on the same device component, then device complexity is reduced, but security is worsened making checksums susceptible to security threats
Solution Approach 1:
The patent physically segments the device into a processor and a separate secure element. The secure element stores checksums and cryptographic keys in its protected memory, while the processor calculates and compares checksums during validation. This segmentation ensures that even if the processor is compromised, the secure element remains protected and can detect firmware tampering through independent checksum validation.
Solution Approach 2:
The secure element acts as an intermediary that independently validates firmware integrity by comparing processor-calculated checksums against stored reference checksums. This intermediary function separates the security-critical validation logic from the main processor, preventing attackers from manipulating both firmware and its validation simultaneously. The secure element mediates the trust relationship between firmware updates and the system.
3Productivity
If firmware updates are transmitted without secure validation, then update speed is improved, but security is worsened allowing malware insertion
Solution Approach 1:
The patent implements preliminary action by pre-loading cryptographic keys and reference checksums into the secure element during device manufacturing, before any firmware updates occur. This preliminary setup enables the secure element to independently validate incoming firmware updates without requiring external validation infrastructure during the update process. The secure element is pre-configured with trust anchors that allow rapid validation of firmware integrity during updates.
Data Source
AI summary
An electronic device, such as a dynamic transaction card having a chip, an applet, and a cryptographic coprocessor performs secure firmware and/or software updates, and performs firmware and/or software validation for firmware and/or software that is stored on the electronic device. Validation may compare a calculated checksum with a checksum stored in the device. If a checksum calculated for a firmware and/or a software application matches a stored checksum, the transaction card may operate normally. If a checksum calculated for a firmware and/or a software application does not match the stored checksum, the transaction card may freeze all capabilities, erase the memory of the transaction card, display data indicative of fraud, and/or the like.