Secure IC Programming with Device Authentication and Certificate Burn-In
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Existing data burning processes lack encryption protection and identity authentication mechanisms, allowing unauthorized access, tampering, and unauthorized data analysis, leakage, and plagiarism in integrated circuits.
Innovation Solution
A secure programming system that uses cryptographic methods and hardware security modules to authenticate devices with paired keys and real-time identity verification, ensuring only authorized devices can operate or control firmware programs in integrated circuits.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Ease of manufacture
If data are burnt into integrated circuit without encryption protection, then burning process is simple and fast, but data can be tampered, leaked and plagiarized by uncertified personnel
Solution Approach 1:
The system performs preliminary encryption of the payload before burning it into the integrated circuit. The authentication module verifies device identity and authenticity before the burning process, ensuring that only authorized devices can receive and operate the burnt data. This preliminary security measure prevents tampering, leakage, and plagiarism while maintaining a streamlined burning process.
Solution Approach 2:
The patent introduces an authentication module as an intermediary between the programmer and the programmable device. This module verifies device identity using cryptographic methods and prevents unauthorized access to the burning process. The intermediary ensures data security without significantly complicating the overall manufacturing process.
2Object-affected harmful factors
If authentication mechanism is added to integrated circuit, then data security is improved, but device complexity increases
Solution Approach 1:
The authentication functionality is extracted as a separate, dedicated module within the programmable device. This modular approach allows the authentication mechanism to be implemented without significantly complicating the overall device architecture. The authentication module operates independently, verifying device identity and ensuring security while leaving the core functional logic relatively simple.
Solution Approach 2:
The authentication mechanism uses self-contained cryptographic methods and verification processes within the device. The device authenticates itself and its operations without requiring complex external verification systems, thereby improving security while minimizing the increase in device complexity.
3Object-affected harmful factors
If real-time identity verification is implemented, then unauthorized access is prevented, but burning task efficiency decreases
Solution Approach 1:
Device identity verification is performed preliminarily before the burning task begins. The authentication module verifies the device's authenticity and authorization status in advance, ensuring that only approved devices can proceed with the burning process. This preliminary verification prevents unauthorized access while allowing efficient burning operations for authenticated devices.
Solution Approach 2:
The authentication process is designed to be rapid and streamlined, allowing verified devices to quickly pass through the verification step and proceed to the burning task. The system efficiently processes authentication requests and minimizes delays for authorized devices, thereby maintaining high productivity while ensuring security.
Data Source
AI summary
A method for operating a secure programming system is provided. Firstly, a first verification code is calculated according to a payload extracted from a job control package. Then, a second verification code is calculated according to the payload burnt into a programmable device. If the first verification code and the second verification code are verified successfully, a burning task is performed. Then, an OEM certificate signing request is generated according to an identifiable information and a programmable device public key. If the OEM certificate signing request is verified successfully, an OEM device certificate is generated and signed with an OEM private key. A third verification code is calculated according to the OEM device certificate. Then, a fourth verification code is calculated according to the OEM device certificate burnt into the programmable device.