An IoT communication encryption system for CPU card management

Abstract

This invention discloses an IoT communication encryption system for CPU card management, relating to the technical field of IoT encryption. It includes an initialization module, a card issuing module, a card reading module, and a platform. A distributed key store is constructed, and based on the access control mechanism of the distributed key store's consortium blockchain, the platform key, manufacturer key, tenant key, and project key are stored in isolation and authorized only to their respective platforms, manufacturers, tenants, and projects. Without the other party's permission, unauthorized access to the keys is impossible. The segmented key design ensures that the platform, manufacturer, tenant, and project each hold their own independent key segment, minimizing the problems caused by the leakage of a single key. Even if an attacker obtains one of the keys, they cannot read the CPU card data; even if an attacker cracks the platform key, they cannot communicate with the initialization device, card issuing device, or card reading device.

Description

Technical Field

[0001] This invention relates to the technical field of IoT encryption, and more particularly to an IoT communication encryption system for CPU card management. Background Technology

[0002] CPU cards possess inherent characteristics such as being difficult to crack, difficult to copy, and highly scalable, making them widely used in scenarios with high security requirements, such as bank cards, payment systems, government services, and transportation cards. CPU cards construct a multi-dimensional defense system through triple authentication of hardware protection layers, secure COS, and key isolation. However, security management needs to cover the entire "card-terminal-system" link. Current security designs include the following:

[0003] Using a combination of CPU cards and SAM cards to ensure end-to-end authentication: This is the solution used in chip-based bank cards. The advantages of this solution are significant. The SAM card stores the user's private key, and authentication can only be performed at dedicated POS machines, ATMs, or counters, effectively ensuring the security of funds in the event of a lost bank card. However, this solution significantly increases the cost of CPU cards and card readers, so it is currently mainly used in scenarios where cost is not a major concern.

[0004] Regularly update keys and enable hybrid transmission mode: While the mechanism of regularly updating keys can effectively reduce the damage caused by key leakage, it will bring a greater workload to management and is not suitable for scenarios such as community access control.

[0005] Prioritizing domestic or international brands that have passed international security certifications ensures a minimum level of card security during the selection phase, but it does not determine the security of the CPU card management process.

[0006] However, with the rapid development of emerging technologies such as AI and quantum computing, it is difficult to solve the security problems in the application process of CPU cards by relying solely on the security of cards and terminals. Summary of the Invention

[0007] To address the aforementioned issues, this invention provides an IoT communication encryption system for CPU card management. For the platform and all manufacturers, tenants, and projects on the platform, the generation, storage, transmission, and verification of keys are seamless. Whether it is the platform, manufacturer, tenant, or project, they are all essentially users on the consortium blockchain. They only need to manage their login account, password, and MFA verification code, further preventing key leakage.

[0008] To achieve the above objectives, the technical solution adopted by the present invention is: to provide an IoT communication encryption system for CPU card management, comprising:

[0009] The initialization module is used to initialize the CPU card's file system, and generate and write the CPU card's root key, application master key, and application key.

[0010] The card issuing module is used to create CPU cards for end users.

[0011] The card reader module is used to verify the data stored in the CPU card, including permission information, verification user information, user operation information, and CPU card balance information.

[0012] On the platform side, it is used to provide IoT communication for the initialization module, card issuing module and card reading module, and to build a remote trusted M2M communication soft bus based on IoT communication; the platform side is connected to the initialization module, card issuing module and card reading module respectively through IoT.

[0013] A distributed key store, connected to the platform, is used to build a distributed key store based on the consortium blockchain and distribute keys. Each module in the system automatically loads the basic information of the CPU card and the key from the distributed key store upon startup. The key includes key data in five dimensions.

[0014] Preferably, the five dimensions include key dimension, manufacturer dimension, tenant dimension, project dimension, and device dimension;

[0015] The key dimension is used to store the UID, basic information, root key, and master key for each application for each card;

[0016] The manufacturer dimension is used to segment the root key and the master key of each application, and to store the CPU card UID and manufacturer key associated with each manufacturer.

[0017] The tenant dimension is used to store the CPU card UID and tenant key associated with each tenant, thereby realizing the binding relationship between the tenant and the CPU card asset.

[0018] The project dimension is used to store the CPU card UID, tenant ID, and project key associated with each project, thereby realizing the binding relationship between projects, tenants, and CPU card assets.

[0019] The device dimension is used to store the tenant, project, and CPU card UID associated with each device, realizing the binding relationship between devices, projects, tenants, and CPU card assets.

[0020] Preferably, in the initialization module, the root key of the card is divided into a platform key and a manufacturer key by reading the card's UID and initializing the file system, the keys of each partition and file, in order to reduce the risk of key leakage.

[0021] Even better, when each partner manufacturer establishes a partnership, the platform operator assigns an independent platform key to the manufacturer and records it into the consortium blockchain.

[0022] The manufacturer key is set by the manufacturer's technicians when each initialization device leaves the factory, and is entered into the consortium blockchain by the platform technicians. When the initialization device is used to initialize the card, after accessing the consortium blockchain, the manufacturer key and platform key of the current initialization device are retrieved from the consortium blockchain to initialize the blank card provided by the manufacturer. Finally, the root key is generated through the SHA256 algorithm. The root key is only used for card initialization operations.

[0023] As a preferred approach, in tenant card management, when a tenant performs operations related to card issuance, loss reporting, unblocking, renewal, and expiration for end users, specifically by operating on a file within a partition of the card, the application key is divided into a tenant key and a project key to reduce the risk of key leakage.

[0024] More preferably, the tenant key is generated autonomously by the tenant's administrator when each tenant is created and written into the consortium blockchain;

[0025] The project key is generated independently by the client's administrators when each project is created and written into the consortium blockchain.

[0026] Even better, after each card issuing and reading device is installed, a tenant and project binding action must be performed to determine the key that needs to be used.

[0027] After the card issuing device and card reading device are started, they pull the tenant key and project key from the consortium blockchain, and use these two keys to generate the final key through the SHA256 algorithm, which is used for reading and writing the card.

[0028] Preferably, the platform key, manufacturer key, tenant key, and project key are stored in isolation through the access control mechanism of the consortium blockchain, and are only authorized for use by the corresponding platform, manufacturer, tenant, and project. Without the permission of the other party, unauthorized access to the key is impossible. The authorized scope of the key is as follows:

[0029] Platform key: Used by the platform and the manufacturer for initializing equipment; different manufacturers use different platform keys.

[0030] Manufacturer key: Used only by the manufacturer for initializing the equipment; different manufacturers have different manufacturer keys.

[0031] Tenant key: Used by the tenant and all its subordinate projects;

[0032] Project key: Used only by the project.

[0033] The beneficial effects of this invention are as follows:

[0034] The connection between the card issuing device and the tenant's computer is most commonly via USB, which is the primary risk of key leakage. Using segmented keys, even if an attacker obtains one of the keys, they cannot eavesdrop on data transmitted through the USB interface.

[0035] The card issuing device and the card reading device usually communicate using a network interface (4G / 5G / WIFI / Ethernet). The communication process is easily eavesdropped. To address this, an encrypted M2M soft bus is used for encrypted communication, and different project networks are isolated through encryption algorithms to establish a virtual project soft bus.

[0036] Since the platform has no access to the manufacturer, tenant, and project keys, even if an attacker breaches the platform, they will be unable to communicate with the initialization device, card issuing device, and card reading device, making subsequent operations impossible. Attached Figure Description

[0037] Figure 1 This is a framework diagram of an IoT communication encryption system for CPU card management according to the present invention. Detailed Implementation

[0038] Please see Figure 1 As shown, the present invention provides an IoT communication encryption system for CPU card management, comprising:

[0039] The initialization module is used to initialize the CPU card's file system, and generate and write the CPU card's root key, application master key, and application key.

[0040] The card issuing module is used to create CPU cards for end users.

[0041] The card reader module is used to verify the data stored in the CPU card, including permission information, verification user information, user operation information, and CPU card balance information.

[0042] On the platform side, it is used to provide IoT communication for the initialization module, card issuing module and card reading module, and to build a remote trusted M2M communication soft bus based on IoT communication; the platform side is connected to the initialization module, card issuing module and card reading module respectively through IoT.

[0043] Hardware composition of this implementation

[0044] Initialization module: includes CPU card reader / writer (model ACR122U), security encryption chip (national cryptographic SM3 / SM4 algorithm chip), industrial computer (memory ≥8GB, storage ≥512GB) and Ethernet communication module;

[0045] Card issuance module: Configure CPU card personalization device (supports ISO7816 protocol), identity recognition module (camera + fingerprint reader), industrial computer (same configuration as initialization module);

[0046] Card reader module: Depending on the scenario, it is divided into access control card reader terminal (integrated RFID antenna and relay control module) and consumption card reader terminal (integrated NFC module and printing module), both equipped with embedded processor (ARM Cortex-M4) and 4G / WiFi communication module;

[0047] Platform side: Deploy IoT gateway (supporting MQTT / CoAP protocol), cloud server (2 8-core 16GB main and backup servers), and consortium blockchain node server (4 nodes, each configured with 16 cores and 32GB server).

[0048] Software module deployment

[0049] Initialization module: Installs file system initialization submodule, key generation and writing submodule, consortium blockchain node client;

[0050] Card issuance module: Card personalization installation submodule, application permission configuration submodule, key loading submodule;

[0051] Card reader module: Includes data verification submodule, operation execution submodule (access control / deduction calculation), and encrypted communication submodule;

[0052] Platform side: Deploy an IoT communication management platform, a trusted M2M soft bus module, and a consortium blockchain key store management system.

[0053] A distributed key store, connected to the platform, is used to build a distributed key store based on the consortium blockchain and distribute keys. Each module in the system automatically loads the basic information of the CPU card and the key from the distributed key store upon startup. The key includes key data in five dimensions.

[0054] The deployment of consortium blockchain nodes involves deploying consortium blockchain nodes on four servers on the platform. The roles of the nodes include: one ledger node, two consensus nodes, and one supervisory node.

[0055] The CA component of Hyperledger Fabric generates node identity certificates for the initialization module, card issuance module, and card reading module respectively, thus completing node access authentication.

[0056] When the initialization module starts, it connects to the consortium blockchain node on the platform via Ethernet and submits the node's identity certificate;

[0057] After verifying the validity of the certificate, the consortium blockchain ledger node returns the root key and application master key corresponding to the initialization module to encrypt the data.

[0058] The initialization module decrypts the data using a local security encryption chip and loads the key into a secure memory area.

[0059] When the card issuing module and card reading module start, repeat steps 1-3 to load the corresponding application key and device identity key respectively, and upload the loading process log to the platform monitoring node in real time.

[0060] Initialization module operation process:

[0061] File system initialization:

[0062] Connect a blank CPU card to the reader / writer, send initialization commands via the ISO7816 protocol, and create the CPU card file system structure: root directory (DF_Root), application directory (DF_Access / DF_Card), and data file (EF_Key / EF_UserInfo).

[0063] Set file access permissions: The root directory is writable only by the initialization module, the application directory is writable only by the card issuing module, and the data files are readable only by the card reading module.

[0064] Key generation and writing:

[0065] The security encryption chip generates a 32-byte root key and an application master key, which are then encrypted using the SM4 algorithm and written to the CPU card's EF_Key file.

[0066] Simultaneously, the key data is uploaded to the distributed key store through the consortium blockchain client, and the uploaded data is accompanied by a digital signature from the initialization module;

[0067] After the consensus node of the consortium blockchain verifies the signature, it updates the key store data and completes key synchronization.

[0068] Card issuance module operation implementation (taking campus card as an example, including but not limited to access control card, community card, and campus card);

[0069] Key and information loading:

[0070] Load the campus card application master key and application key from the distributed key store, decrypt them and store them in the local secure area;

[0071] The user information (student ID, name, photo) is collected through the identity recognition submodule, and a user data file is generated.

[0072] Personalized card creation:

[0073] Connect a blank CPU card to the personalized device, first write the application key to the EF_Key file, and then write the user information to the EF_UserInfo file;

[0074] Send a card activation command, set the card status to "available", and generate a unique card identifier (CardID).

[0075] The CardID, user information, and application key association data are uploaded to the platform and synchronously updated to the distributed key store.

[0076] Card reader module operation implementation (taking access control verification as an example, including but not limited to verifying access control permissions, verifying user information, and deducting payment):

[0077] Communication and Key Acquisition:

[0078] The card reader module connects to the platform's trusted M2M soft bus via a 4G module to send access control verification requests (including the card reader module device ID and access control area ID).

[0079] The platform-side soft bus module matches the corresponding application key and sends it to the card reader module through end-to-end encryption.

[0080] Card verification process:

[0081] When a user swipes their card, the card reader module reads data from the CPU card's EF_Key and EF_UserInfo files via the RFID antenna;

[0082] The SM4 algorithm is used to decrypt the card application key and compare it with the application key issued by the platform. If the comparison is successful, the access control permissions in the user information are verified to match the current area. If the verification is successful, an opening command is sent to the relay module.

[0083] The entire verification process log (CardID, verification time, result) is uploaded to the platform for storage via an encrypted channel.

[0084] Implementation process of distributed end-to-end encryption technology:

[0085] Communication link encryption:

[0086] Communication between the initialization module and the platform: An encrypted channel is established using the TLS 1.3 protocol, and the client (initialization module) and the server (platform) perform two-way authentication using the device identity key;

[0087] Communication between the card reader module and the platform: Based on the MQTT protocol, the communication data (such as verification requests and key distribution) is encrypted using the SM4 algorithm, and the session key is generated by the identity keys of the two devices.

[0088] The trusted M2M soft bus ensures that inter-device communication is tamper-proof and cannot be stolen through a four-step mechanism of "device identity authentication - session key negotiation - data encryption transmission - integrity verification".

[0089] Key update and security:

[0090] When the application key is about to expire (7 days remaining), the platform's key store management system automatically generates a new key and distributes it to each terminal through an encrypted channel.

[0091] Once each end receives the new key, the old key immediately becomes invalid, ensuring the key's timeliness.

[0092] If an anomaly occurs at a certain end (such as the card reader module) (such as key leakage), the platform can issue a key freezing command through the consortium blockchain node to terminate the key usage rights of that end and ensure the overall security of the system.

[0093] The five dimensions include key dimension, manufacturer dimension, tenant dimension, project dimension, and equipment dimension;

[0094] Key dimension: Stores the UID, basic information, root key, and master key for each card and each application.

[0095] Manufacturer Dimension: Stores the CPU card UID and manufacturer key associated with each manufacturer, thereby establishing a binding relationship between the manufacturer and the CPU card asset. The manufacturer key is mainly used for segmenting the root key and the master key for each application.

[0096] Tenant dimension: Stores the CPU card UID and tenant key associated with each tenant, thereby realizing the binding relationship between the tenant and the CPU card asset.

[0097] Project Dimension: Stores the CPU card UID, tenant ID, and project key associated with each project, thereby realizing the binding relationship between projects, tenants, and CPU card assets.

[0098] Device dimension: Stores the tenant, project, and CPU card UID associated with each device, thereby realizing the binding relationship between devices, projects, tenants, and CPU card assets.

[0099] This invention uses segmented keys in two scenarios to ensure that the keys are not intercepted during the management process.

[0100] 1. Card Manufacturing by the Manufacturer: During card manufacturing, the card needs to be initialized by reading its UID and initializing the keys for the file system, various partitions, and files. At this stage, we manage the card's root key in two segments: a platform key and a manufacturer key, to reduce the risk of key leakage.

[0101] When establishing a partnership, each manufacturer is assigned a unique platform key by the platform operators, which is then entered into the consortium blockchain.

[0102] When each initialization device leaves the factory, the manufacturer's technicians set the manufacturer's key for card initialization, and the platform's technicians entered it into the consortium blockchain.

[0103] When initializing a card using an initialization device, the dedicated software, after registering with the consortium blockchain, will retrieve the manufacturer's key and platform key of the current initialization device from the consortium blockchain to initialize the blank card provided by the manufacturer.

[0104] Final key generation algorithm: SHA256 (manufacturer key + platform key).

[0105] The card root key is used only for card initialization and not for any other purpose.

[0106] 2. Tenant Card Management: When tenants perform operations such as issuing cards, reporting lost cards, unblocking cards, renewing cards, and deactivating cards for end users, they need to operate on a specific file in a specific partition of the card. At this time, we manage the application key in two segments: the tenant key and the project key, to reduce the risk of key leakage.

[0107] When a tenant is created, its administrators generate a tenant key and write it into the consortium blockchain.

[0108] When each project is created, the client's administrators independently generate a project key and write it into the consortium blockchain.

[0109] After each card issuing and reading device is installed, a tenant and project binding action must be performed to determine the key required for its use.

[0110] After the card issuing device and card reading device are started, they pull the tenant key and project key from the consortium blockchain and use these two keys to generate the final key, which is used for reading and writing the card.

[0111] Final key generation algorithm: SHA256 (manufacturer key + platform key).

[0112] The card application key is used only by the tenant to manage cards for subordinate projects and is not used for other purposes.

[0113] This invention utilizes a consortium blockchain's access control mechanism to isolate and store platform keys, manufacturer keys, tenant keys, and project keys, authorizing their use only to their respective platforms, manufacturers, tenants, and projects. Unauthorized access to these keys is impossible without the other party's permission. This design ensures that each platform, manufacturer, tenant, and project holds its own independent key segment, minimizing the problems caused by the leakage of a single key. The authorization scope of these four keys is as follows:

[0114] Platform key: Available for both the platform and the manufacturer's initialization equipment; different manufacturers use different platform keys.

[0115] Manufacturer key: Only available for the manufacturer's initialization equipment; different manufacturers have different manufacturer keys.

[0116] Tenant key: Available to the tenant and all its subordinate projects.

[0117] Project key: Available only for projects.

[0118] Key transparency mechanism: For the platform and all manufacturers, tenants and projects on the platform, the generation, storage, transmission and verification of keys are seamless. Whether it is the platform, manufacturer, tenant or project, they are actually all users on the consortium blockchain. They only need to manage the account, password and MFA verification code for logging into the platform, which further prevents the problem of key leakage.

[0119] The application scenarios for the key of this invention include:

[0120] Card operations: These include card initialization, card issuance, reporting a lost card, unblocking a card, renewal, and expiration.

[0121] M2M soft bus communication: Primarily used to achieve encrypted communication between card issuing and reading devices within the same project. Details are as follows:

[0122] Only card issuing and reading devices within the same project need and can perform M2M communication.

[0123] The M2M communication message payload between the card issuing device and the card reading device is encrypted using the HMAC encryption algorithm, and the key for the HMAC encryption algorithm is the "application key" of the current project.

[0124] Since the platform does not have access to the tenant key and project key, it is also unable to generate an "application key". This means that the platform cannot listen to M2M communication messages under the project, but only transparently forwards the messages to realize M2M communication capabilities.

[0125] The structure of an encrypted communication message includes the sender device ID, receiver device ID, message serial number, data length, encryption payload, and checksum.

[0126] The above embodiments are merely descriptions of preferred embodiments of the present invention and are not intended to limit the scope of the present invention. Various modifications and improvements made by those skilled in the art to the technical solutions of the present invention without departing from the spirit of the present invention should fall within the protection scope defined by the claims of the present invention.

Claims

1. An IoT communication encryption system for CPU card management, characterized in that, include: The initialization module is used to initialize the CPU card's file system, and generate and write the CPU card's root key, application master key, and application key. The card issuing module is used to create CPU cards for end users. The card reader module is used to verify the data stored in the CPU card, including permission information, verification user information, user operation information, and CPU card balance information. On the platform side, it is used to provide IoT communication for the initialization module, card issuing module and card reading module, and to build a remote trusted M2M communication soft bus based on IoT communication; the platform side is connected to the initialization module, card issuing module and card reading module respectively through IoT. A distributed key store, connected to the platform, is used to build a distributed key store based on the consortium blockchain and distribute keys. Each module in the system automatically loads the basic information of the CPU card and the key from the distributed key store upon startup. The key includes key data in five dimensions.

2. The IoT communication encryption system for CPU card management according to claim 1, characterized in that, The five dimensions include key dimension, manufacturer dimension, tenant dimension, project dimension, and equipment dimension; The key dimension is used to store the UID, basic information, root key, and master key for each application for each card; The manufacturer dimension is used to segment the root key and the master key of each application, and to store the CPU card UID and manufacturer key associated with each manufacturer. The tenant dimension is used to store the CPU card UID and tenant key associated with each tenant, thereby realizing the binding relationship between the tenant and the CPU card asset. The project dimension is used to store the CPU card UID, tenant ID, and project key associated with each project, thereby realizing the binding relationship between projects, tenants, and CPU card assets. The device dimension is used to store the tenant, project, and CPU card UID associated with each device, realizing the binding relationship between devices, projects, tenants, and CPU card assets.

3. The IoT communication encryption system for CPU card management according to claim 1, characterized in that, In the initialization module, the card's UID is read and the keys for the file system, each partition, and the files are initialized. The root key of the card is divided into a platform key and a manufacturer key to reduce the risk of key leakage.

4. The IoT communication encryption system for CPU card management according to claim 3, characterized in that, The platform key is assigned to each partner manufacturer by the platform operators when establishing cooperation, and is then entered into the consortium blockchain. The manufacturer key is set by the manufacturer's technicians when each initialization device leaves the factory, and is entered into the consortium blockchain by the platform technicians. When the initialization device is used to initialize the card, after accessing the consortium blockchain, the manufacturer key and platform key of the current initialization device are retrieved from the consortium blockchain to initialize the blank card provided by the manufacturer. Finally, the root key is generated through the SHA256 algorithm. The root key is only used for card initialization operations.

5. The IoT communication encryption system for CPU card management according to claim 1, characterized in that, In tenant card management, when a tenant performs operations such as card issuance, card loss reporting, card unblocking, card renewal, and card expiration for end users, the operation is specifically performed on a file in one of the card's partitions. In this case, the application key is divided into a tenant key and a project key to reduce the risk of key leakage.

6. The IoT communication encryption system for CPU card management according to claim 5, characterized in that, The tenant key is generated autonomously by the tenant's administrator when each tenant is created and written into the consortium blockchain; The project key is generated independently by the client's administrators when each project is created and written into the consortium blockchain.

7. The IoT communication encryption system for CPU card management according to claim 6, characterized in that, After each card issuing and reading device is installed, a tenant and project binding action must be performed to determine the key required for its use. After the card issuing device and card reading device are started, they pull the tenant key and project key from the consortium blockchain, and use these two keys to generate the final key through the SHA256 algorithm, which is used for reading and writing the card.

8. The IoT communication encryption system for CPU card management according to claim 1, characterized in that, The access control mechanism of the consortium blockchain isolates and stores platform keys, manufacturer keys, tenant keys, and project keys, and authorizes their use only by the corresponding platform, manufacturer, tenant, and project. Without the permission of the other party, unauthorized access to the keys is impossible. The authorized scope of the keys is as follows: Platform key: Used by the platform and the manufacturer for initializing equipment; different manufacturers use different platform keys. Manufacturer key: Used only by the manufacturer for initializing the equipment; different manufacturers have different manufacturer keys. Tenant key: Used by the tenant and all its subordinate projects; Project key: Used only by the project.

Images