Lightweight equipment authorization token for Internet of Things equipment and generation, transmission and verification method thereof

Abstract

The invention relates to a lightweight equipment authorization token for Internet of Things equipment and a generation, transmission and verification method thereof. The method comprises the following steps: step 1, definition and structure of a DAT; step 2, a DAT generation process; step 3, a DAT transmission process; according to the scheme, the security is high, through triple guarantee of'extremely short time efficiency '(second level), 'equipment and operation strong binding' and'digital signature verification ', even if the DAT is intercepted in a non-secure BLE channel, an attacker almost cannot complete a replay attack within the validity period, the system security is greatly improved, and the flexibility and the expandability are high.

Description

TECHNICAL FIELD

[0001] The application relates to a method, in particular to a lightweight device authorization token for an Internet of Things device and a generation, transmission and verification method thereof, and belongs to the technical field of artificial intelligence application. BACKGROUND

[0002] In the "invisible geofencing TOTP" scenario, there is a key contradiction:

[0003] Security requirement: the Internet of Things device (such as a door lock) that finally performs an operation (such as unlocking) must receive an authorized instruction with strong authentication, anti-replay and time limit;

[0004] In the invisible authentication scenario combining time-based one-time password (TOTP) and geofencing, there is a key contradiction: on the one hand, the Internet of Things terminal device (such as a smart door lock, a car lock, etc.) that performs a physical operation must receive an authorized instruction with strong authentication, anti-replay and time limit to ensure the security of the operation; on the other hand, such devices are usually limited in network connection capability (such as supporting only Bluetooth communication), computing resources (MCU-level processor, limited memory) and power consumption budget, and are difficult to directly participate in complex cloud authentication processes or perform high-overhead cryptographic operations.

[0005] In the prior art, there are various solutions to solve this problem, but there are still significant defects:

[0006] If the TOTP is verified locally by the device, the device needs to store the user key seed and maintain high-precision clock synchronization, which significantly increases the cost and complexity of the device, and the transmission of the TOTP code through a short-range wireless channel (such as BLE) is vulnerable to man-in-the-middle attacks or replay attacks;

[0007] If the device directly verifies the cloud, the device needs to have stable network connection and complete TLS communication capability, which is not suitable for low-power, intermittent communication Internet of Things devices;

[0008] If a long-term valid access token is used as an intermediary by a mobile phone, there is a long-term risk of token leakage, which violates the "zero trust" security model and the "least privilege" principle.

[0009] Therefore, the prior art lacks a mechanism that can complete strong authentication on the server and securely transmit the authentication decision to resource-constrained Internet of Things devices in a lightweight, short-time, anti-replay and low verification overhead manner, making it difficult to balance security and device cost, power consumption and connectivity SUMMARY

[0010] The present application is just for the technical problems existing in the prior art, providing a lightweight device authorization token (DAT) generation, transmission and verification method suitable for resource-constrained Internet of Things devices, to overcome the problems of insufficient security, high cost or poor feasibility caused by the inability of devices to directly participate in cloud authentication, insecure near-distance communication channels, limited device computing and storage resources in the prior art.

[0011] The related parameters of the present application are explained as follows:

[0012]

[0013] In order to achieve the above-mentioned purpose, the technical scheme of the present application is as follows: a lightweight device authorization token for Internet of Things devices and a generation, transmission and verification method thereof, the method comprising the following steps:

[0014] Step 1: Definition and structure of DAT,

[0015] Step 2: DAT generation process,

[0016] Step 3: DAT transmission process,

[0017] Step 4: DAT verification and execution process.

[0018] Among them, step 1: definition and structure of DAT, specifically as follows:

[0019] DAT is an encrypted data packet generated by an authentication server, used to authorize a specific Internet of Things device to execute a specific operation within a very short time, and its core structure is as follows:

[0020]

[0021]

[0022] Key features:

[0023] Lightweight: only contains necessary fields, total data size is less than 200 bytes, suitable for transmission through BLE, NFC and other low-bandwidth, low-power communication channels.

[0024] Short time limit: the validity period is usually 5-30 seconds, which greatly compresses the time window for replay attacks after the token is intercepted.

[0025] Strong binding: explicitly binds the target device ID and operation type, preventing the token from being used for other devices or illegal operations.

[0026] Anti-replay: through the double mechanism of globally unique dat_id and random nonce, it is ensured that each token can only be used once.

[0027] Verifiable: Ensure DAT is issued by legitimate service through digital signature, prevent forgery and tampering.

[0028] To adapt to devices without high-precision local clock, two verification modes are provided:

[0029] Mode 1 (recommended): The device has basic clock capability and can perform time window verification;

[0030] Mode 2 (innovative enhancement): The device has no RTC or unreliable clock, and uses "heartbeat sequence number binding" or "challenge-response" mechanism instead of time verification, completely getting rid of dependence on local time.

[0031] Among them, step 2: DAT generation process, as follows,

[0032] DAT generation process, in the authentication server, the server successfully verifies the user's identity, including TOTP code, geographic location, device context multi-factor information, confirms the authorization request is legal,

[0033] The server generates a globally unique dat_id and a one-time nonce,

[0034] According to the authorization policy, fill in device_id, operation, issued_at, expires_at field, use the server private key to sign all the above fields (or their hash value), generate signature, assemble the complete DAT data packet,

[0035] The server performs the following operations in parallel:

[0036] a) Push to mobile App: Send DAT to user mobile App through HTTPS and other secure channels for subsequent close-range transmission;

[0037] b) Push to target device (if the device is online): Push directly through MQTT over TLS, CoAP secure Internet of Things protocol;

[0038] If the device is offline, DAT can be cached on the server, pulled when the device next heartbeat, or completely rely on the mobile App as a relay.

[0039] User identity verification (such as TOTP, geographic location, device behavior analysis) is completely completed on the server;

[0040] DAT is only a secure encapsulation of "authentication results", and the device does not need to participate in the original authentication logic;

[0041] The device only needs to verify the signature and does not touch any user key.

[0042] "Authentication logic is completely decoupled from the execution terminal", so that resource-constrained devices can also enjoy strong authentication protection.

[0043] Among them, step 3: DAT delivery process, from the server to the device, as follows,

[0044] Support dual-channel delivery mechanism, adapt to different network conditions of the device:

[0045] Mode A: mobile phone as "messenger", suitable for no network / weak network devices,

[0046] Mobile phone App receives DAT issued by the server,

[0047] App actively scans the surrounding BLE devices, identifies the target device (based on device_id or broadcast name); through encrypted BLE communication, DAT is safely transmitted to the target device; the device returns ACK after receiving DAT, and the App feeds back to the user "authorization has arrived at the device"; the mobile phone App combines UWB, RSSI ranging or multi-sensor fusion (acceleration, gyroscope) to judge whether the user is really "close" to the device;

[0048] Only when the distance is less than the threshold (such as 1 meter) and the motion state matches, DAT is sent;

[0049] Prevent attackers from simulating "close" behavior at a distance through relay devices, integrate physical layer context information into the delivery process, and build a security boundary against relay attacks.

[0050] Through close-range communication combined with context awareness, prevent long-distance relay attacks.

[0051] Mode B: device directly connects to the server, the server pushes DAT directly to the device through MQTT / CoAPs protocol, the device receives and verifies DAT, and the server sends a notification to the mobile phone App: "authorization has been successfully issued to the device", the App can display "device ready" state, and prompt the user to approach the device to complete the operation (such as touching the door handle to automatically unlock), improve the no-touch experience.

[0052] Among them, step 4: DAT verification and execution process, as follows,

[0053] At the device end of the Internet of Things,

[0054] After the device receives DAT, the following verification process is performed:

[0055] Receive: the device receives the DAT data packet,

[0056] Time effectiveness or state validity check, supporting two modes:

[0057] Mode 1: Based on local time, the device checks if the current local time is between issued_at and expires_at, if out of range, directly discard,

[0058] Mode 2: No clock dependency, if DAT contains last_heartbeat_seq field, the device checks if it is equal to the current heartbeat sequence number or within the allowed offset range (±2);

[0059] Or if challenge-response mechanism is used, the device verifies if the bound_challenge in DAT matches the last issued challenge,

[0060] Anti-replay check: The device queries the local "used token cache" to check if dat_id or nonce already exists, if exists, refuse to execute;

[0061] Target check: Verify if device_id matches the device ID itself to prevent cross-device abuse;

[0062] Signature verification: Use the pre-set server public key to verify the signature of DAT, if failed, refuse to execute; Perform operation: After all checks pass, execute the operation specified by operation (such as driving the motor to unlock);

[0063] Record and feedback:

[0064] Add dat_id to the "used token list" and clean up expired items regularly;

[0065] Through close-range communication or network, report "operation success / failure" status to the mobile App or server.

[0066] Through BLE or network channel, report "operation success / failure" status to the mobile App or server;

[0067] The reported information can include result code, timestamp, power, etc. context, for user feedback and operation and maintenance monitoring;

[0068] If the device has low-power display capability (such as electronic ink screen), it can display "unlocked" or "authorization failed" prompt locally, enhancing user experience.

[0069] An electronic device, comprising a memory, a processor, and a computer program stored on the memory and executable on the processor, wherein the processor executes the program to implement the lightweight device authorization token for Internet of Things devices and its generation, transmission, and verification method.

[0070] A computer readable storage medium, having stored thereon computer instructions, which when executed by a processor implement the method for lightweight device authorization token for internet of things device and generation, delivery and verification thereof.

[0071] Compared with the prior art, the present application has the following advantages: 1. High safety: three safeguards of "very short time limit" (second level), "strong binding of device and operation", and "digital signature verification" greatly improve the safety of the system, even if the DAT is intercepted in a non-secure BLE channel, the attacker is almost impossible to complete a replay attack within the validity period;

[0072] 2. Low device requirement: the most complex TOTP and location verification logic is placed in the cloud and the mobile phone, and the internet of things device only needs to perform lightweight DAT verification (mainly symmetric or asymmetric signature verification), which has very low requirements for the computing power, storage space and network connection of the device, and is suitable for large-scale deployment in resource-limited internet of things devices;

[0073] 3. Strong flexibility: the innovative double delivery mechanism (mobile phone transfer / device direct connection) perfectly adapts to the diversified network environment of internet of things devices, whether it is a smart gateway with network or a pure Bluetooth door lock without network, it can be seamlessly connected;

[0074] 4. Good user experience: as the core component of the "unconscious authentication" scheme, the DAT mechanism enables the user to automatically and safely complete the operation when approaching the device without any manual intervention, realizing the perfect unity of safety and convenience;

[0075] 5. Good scalability: the structure design of DAT is simple and standardized, easy to support more operation types and more complex strategies (such as time limit), and can be widely applied to smart door locks, shared cars, industrial control, medical devices and other internet of things scenarios. BRIEF DESCRIPTION OF DRAWINGS

[0076] Figure 1 The figure is a schematic diagram of the overall framework of the present application. DETAILED DESCRIPTION

[0077] In order to deepen the understanding of the present application, the present embodiment will be described in detail below with reference to the accompanying drawings.

[0078] Embodiment 1: see Figure 1 A lightweight device authorization token for internet of things devices and a method for generating, delivering and verifying the same, the method comprising the following steps:

[0079] Step 1: definition and structure of DAT,

[0080] Step 2: DAT generation process,

[0081] Step 3: DAT delivery process,

[0082] Step 4: DAT verification and execution process.

[0083] Wherein, Step 1: Definition and structure of DAT, as follows:

[0084] DAT is an encrypted data packet generated by an authentication server to authorize specific IoT devices to perform specific operations within a very short time. Its core structure is as follows:

[0085]

[0086] Key features:

[0087] Lightweight: Only contains necessary fields, total data size is less than 200 bytes, suitable for transmission through low-bandwidth and low-power communication channels such as BLE and NFC.

[0088] Short expiration: Validity period is usually 5-30 seconds, greatly compressing the time window for replay attacks if the token is intercepted.

[0089] Strong binding: Explicitly binds target device ID and operation type, preventing tokens from being used for other devices or illegal operations.

[0090] Anti-replay: Through the dual mechanisms of globally unique dat_id and random nonce, ensures that each token can only be used once.

[0091] Verifiable: Through digital signature to ensure that DAT is issued by a legitimate server, preventing forgery and tampering.

[0092] To accommodate devices without high-precision local clocks, two verification modes are provided:

[0093] Mode 1 (recommended): Devices have basic clock capabilities and can perform time window verification;

[0094] Mode 2 (innovative enhancement): Devices without RTC or unreliable clocks use "heartbeat sequence number binding" or "challenge-response" mechanism instead of time verification, completely eliminating dependence on local time.

[0095] Wherein, Step 2: DAT generation process, as follows,

[0096] DAT generation process, in the authentication server, the server successfully verifies user identity, including TOTP code, geographic location, device context multi-factor information, confirms that the authorization request is legal,

[0097] The server generates a globally unique dat_id and a one-time nonce,

[0098] According to the authorization policy, fill in the device_id, operation, issued_at, expires_at fields, digitally sign all the above fields (or their hash values) using the server private key, generate signature, assemble the complete DAT data packet,

[0099] The server performs the following operations in parallel:

[0100] a) Push to mobile App: Send DAT to user mobile App through a secure channel such as HTTPS for subsequent close-range delivery;

[0101] b) Push to target device (if device is online): Directly issue through MQTT over TLS, CoAP secure Internet of Things protocol;

[0102] If the device is offline, DAT can be cached on the server, pulled when the device next heartbeat, or completely rely on the mobile App as one of them, Step 3: DAT delivery process, from the server to the device, as follows,

[0103] Support dual-channel delivery mechanism, adapt to devices under different network conditions:

[0104] Mode A: Mobile phone as "messenger", suitable for no network / weak network devices,

[0105] Mobile App receives DAT issued by the server, mobile App combines UWB, RSSI ranging or multi-sensor fusion (acceleration, gyroscope) to determine whether the user is truly "close" to the device;

[0106] Only when the distance is less than the threshold (such as 1 meter) and the motion state matches, DAT is sent;

[0107] Prevent attackers from simulating "close" behavior at a distance through relay devices, integrate physical layer context information into the delivery process, and build a secure boundary against relay attacks.

[0108] Through close-range communication combined with context awareness, prevent remote relay attacks.

[0109] Mode B: Device directly connected to the server (suitable for networked devices)

[0110] The server sends DAT directly to the device through a secure channel (such as MQTT over TLS),

[0111] The device receives DAT,

[0112] Reply to the server that DAT has been received,

[0113] The server notifies the mobile App that "authorization has been issued", and the App feeds back the status to the user.

[0114] Step 4: DAT verification and execution process, as follows,

[0115] At the IoT device end,

[0116] After the device receives the DAT, the following verification process is performed:

[0117] Receive: The device receives the DAT data packet,

[0118] Time effectiveness or state validity check, supporting two modes:

[0119] Mode 1: Based on local time, the device checks whether the current local time is between issued_at and expires_at. If it is out of range, it is discarded directly,

[0120] Mode 2: No clock dependency. If the DAT contains the last_heartbeat_seq field, the device checks whether it is equal to the current heartbeat sequence number or within the allowed offset range (such as ±2);

[0121] Or if a challenge-response mechanism is used, the device verifies whether the bound_challenge in the DAT matches the last challenge issued,

[0122] Anti-replay check: The device queries the local "used token cache" to check whether dat_id or nonce already exists. If it exists, it is rejected for execution;

[0123] Target check: Verify whether the device_id matches the device ID itself to prevent cross-device abuse;

[0124] Signature verification: Use the pre-set server public key to verify the signature of the DAT. If it fails, it is rejected for execution; Execute operation: After all checks pass, execute the operation specified by operation (such as driving the motor to unlock);

[0125] Record and feedback:

[0126] Add dat_id to the "used token list" and clean up expired items regularly;

[0127] Through close-range communication or network, report "operation success / failure" status to the mobile phone App or server.

[0128] Embodiment 2: Application to the scene of non-inductive unlocking of smart door locks

[0129] 1. System initialization

[0130] User pairs with smart lock via mobile app. During pairing, the public key of the authentication server (Server_Pub_Key) is pre-stored in the security chip (SE) of the lock. Meanwhile, the device_id of the lock (e.g. LOCK_HOME_001) and its bound user information are recorded in the server database.

[0131]

[0132] User_TOTP_Seed is securely stored in the user app for generating TOTP.

[0133] 2. User approaches to trigger authentication

[0134] User approaches the home door with the mobile phone, and the smart lock periodically broadcasts its device_id.

[0135] The mobile app detects that the signal strength of LOCK_HOME_001 reaches a threshold (e.g. RSSI>-70dBm), and automatically triggers the frictionless authentication process.

[0136] The app generates the current TOTP code (e.g. 582174) based on the current time and User_TOTP_Seed, and sends the code along with the location proof (RSSI value, timestamp, Nonce) to the authentication server via HTTPS.

[0137] 3. Server generates and distributes DAT

[0138] After verifying that the TOTP code is valid and the location information is compliant, the server decides to authorize the unlocking.

[0139] The server generates DAT:

[0140] device_id: "LOCK_HOME_001"

[0141] operation: "UNLOCK"

[0142] issued_at: 1738320000 (current time)

[0143] expires_at: 1738320010 (10 seconds later)

[0144] dat_id: "DAT_A1B2C3D4E5F6"

[0145] nonce: "x7y8z9a0b1c2"

[0146] signature: The server signs the above fields with its private key.

[0147] ​• The server sends the DAT to the user's phone App via HTTPS.

[0148] • At the same time, the server tries to push the DAT to the smart lock via MQTT over TLS (assuming the lock is online).

[0149] 4. DAT delivery and verification

[0150] Case A (lock is online): The lock receives the DAT directly from the server. The lock MCU checks that the current time (1738320005) is within the validity period, the dat_id is not used, the device_id matches, and the Server_Pub_Key successfully verifies. The lock immediately drives the motor to unlock and adds the dat_id to the used list.

[0151] Case B (lock is offline): The lock does not receive the server push. After receiving the DAT, the phone App sends the DAT to the lock via BLE Secure Connection. The lock performs the same verification steps as Case A, and unlocks after verification.

[0152] 5. User experience

[0153] The user does not need to open the App or enter any password. When the user walks to the door, the lock automatically opens, and the phone App pushes a notification "the door is open".

[0154] It should be noted that the above embodiments are not intended to limit the scope of protection of the present application, and any equivalent transformations or substitutions made on the basis of the above technical solutions fall within the scope of protection of the claims of the present application.

Claims

1. A lightweight device authorization token for Internet of Things devices and its generation, delivery and verification method, characterized in that, The method comprises the following steps: Step 1: Definition and structure of DAT, Step 2: DAT generation process, Step 3: DAT delivery process, Step 4: DAT verification and execution process.

2. The lightweight device authorization token for Internet of Things devices and its generation, delivery and verification method according to claim 1, characterized in that, Step 1: Definition and structure of DAT, specifically as follows: DAT is an encrypted data packet generated by the authentication server, used to authorize specific Internet of Things devices to perform specific operations within a very short time, and its core structure is as follows: { "dat_id":"DAT_9a8b7c6d5e", "device_id":"LOCK_123456", "operation":"UNLOCK", "issued_at":1738320000, "expires_at":1738320010, "nonce":"x7y8z9a0b1c2", "signature":"a1b2c3...x9y0"; } To adapt to devices without high-precision local clocks, two verification modes are provided: Mode 1: The device has basic clock capability and performs time window verification; Mode 2: The device has no RTC or unreliable clock, and uses "heartbeat sequence number binding" or "challenge-response" mechanism instead of time verification, completely eliminating the dependence on local time.

3. The lightweight device authorization token for Internet of Things devices and its generation, delivery and verification method according to claim 1, characterized in that, Step 2: DAT generation process, specifically as follows, DAT generation process, at the authentication server, The server successfully verifies the user's identity, including TOTP code, geographic location, device context multi-factor information, and confirms that the authorization request is legal, The server generates a globally unique dat_id and a one-time nonce, According to the authorization policy, fill in the device_id, operation, issued_at, expires_at fields, Use the server's private key to digitally sign all the above fields or their hash values to generate a signature, Assemble the complete DAT data packet, The server performs the following operations in parallel: a) Push to mobile App: Send DAT to user mobile App through HTTPS and other secure channels for subsequent close-range delivery; b) Push to target device, if device is online: directly issue through MQTT over TLS, CoAP secure Internet of Things protocol; if the device is offline, DAT can be cached on the server, pulled when the device next heartbeat, or completely rely on the mobile App as a relay.

4. The lightweight device authorization token for Internet of Things devices and its generation, delivery and verification method according to claim 1, characterized in that, Step 3: DAT delivery process, from server to device, specifically as follows, Support dual-channel delivery mechanism, adapt to devices under different network conditions: Mode A: Phone as "messenger", suitable for no / weak network equipment, App receives DAT issued by server, App actively scans surrounding BLE devices, identifies target device (based on device_id or broadcast name); DAT is securely transmitted to target device through encrypted BLE communication; device returns ACK after receiving DAT, App feedbacks "authorization has arrived at device" to user Mode B: Device directly connects to server, server pushes DAT directly to device through MQTT / CoAPs protocol, device receives and verifies DAT, server sends notification to App: "authorization has been successfully issued to device", App displays "device is ready" state and prompts user to complete operation close to device, improving non-conscious experience.

5. The lightweight device authorization token for Internet of Things devices and its generation, transmission and verification method according to claim 1, characterized in that, Step 4: DAT verification and execution process, specifically as follows, at the Internet of Things device end, the device receives DAT and performs the following verification process: Receive: The device receives the DAT data packet, Time effectiveness or state validity check, supporting two modes: Mode one: based on local time, the device checks whether the current local time is between issued_at and expires_at, if it is out of range, it is directly discarded, Mode two: no clock dependence, If the DAT contains the last_heartbeat_seq field, the device checks whether it is equal to the current heartbeat sequence number or within the allowed offset range; Or if the challenge-response mechanism is used, the device verifies whether the bound_challenge in the DAT matches the latest challenge issued, Anti-replay check: the device queries the local "used token cache" to check whether dat_id or nonce already exists, if it exists, it is rejected; Target check: verify whether the device_id matches the device ID itself to prevent cross-device abuse; Signature verification: use the pre-set server public key to verify the signature of DAT, if it fails, reject execution; Execute operation: after all checks pass, execute the operation specified by operation; Record and feedback: Add dat_id to the "used token list" and clean up expired items regularly; Report "operation success / failure" status to the phone App or server through BLE or network channel; The reported information can include result code, timestamp, power and other context for user feedback and operation and maintenance monitoring; If the device has low-power display capability (such as electronic ink screen), it can display "unlocked" or "authorization failed" locally to enhance user experience.

6. An electronic device comprising a memory, a processor, and a computer program stored on the memory and executable on the processor, characterized in that, The processor executes the program to realize the lightweight device authorization token for Internet of Things devices and its generation, transmission and verification method according to any one of claims 1 to 5.

7. A computer readable storage medium having stored thereon computer instructions, wherein, The computer instructions are executed by the processor to realize the lightweight device authorization token for Internet of Things devices and its generation, transmission and verification method according to any one of claims 1 to 5.

Images