A Security Protocol for the Identification and Data Encrypt Key Management of Secure Mobile Devices

In this paper, we proposed an identification and data encrypt key manage protocol that can be used in some security system based on such secure devices as secure USB memories or RFIDs, which are widely used for identifying persons or other objects recently. In general, the default functions of the security system using a mobile device are the authentication for the owner of the device and secure storage of data stored on the device. We proposed a security model that consists of the server and mobile devices in order to realize these security features. In this model we defined the secure communication protocol for the authentication and management of data encryption keys using a private key encryption algorithm with the public key between the server and mobile devices. In addition, we was performed the analysis for the attack to the communication protocol between the mobile device and server. Using the communication protocol, the system will attempt to authenticate the mobile device. The data decrypt key is transmitted only if the authentication process is successful. The data in the mobile device can be decrypted using the key. Our analysis proved that this Protocol ensures anonymity, prevents replay attacks and realizes the interactive identification between the security devices and the authentication server.

💡 Research Summary

The paper proposes an identification and data‑encryption‑key management protocol designed for secure mobile devices such as encrypted USB sticks, smart cards, and RFID tags. The authors describe a system architecture that consists of three logical entities: (1) a set of secure storage devices (the “D” devices) that store a unique device identifier (D ID) and a random number (D r) assigned by the server, (2) an authentication server that maintains a database of all device signatures (DSig) and holds the private key of an asymmetric public‑key cryptosystem (PKE), and (3) a broker that merely forwards messages between devices and the server.

The protocol is divided into a preparation phase and an authentication phase. In the preparation phase the server generates a per‑device random value D r, stores the pair (D ID, key) as a signature DSig, and records D ID ∥ H(D r) as a primary search key. In the authentication phase the broker initiates the exchange by sending a “Hello” message to a device. The device computes x = H(D ID ⊕ D r) and encrypts a symmetric key component C x with the server’s public key, then sends the tuple (x, D r, C x) to the server. The server decrypts C x, verifies that the received x matches the hash of the stored D ID and D r, and confirms the device’s identity by looking up DSig using D ID ∥ H.

If verification succeeds, the server generates a fresh random value new r, derives a new hash‑based value new D r ID H = H(new r ⊕ D ID), encrypts a new symmetric key using PBKDF2 with parameters (new r ID, iteration count c, output length dkLen), and sends (new r H, new D r ID H, new DSig) back to the device through the broker. The device validates the new hash, recomputes the PBKDF2‑derived key, checks that the D ID embedded in the received DSig matches its own identifier, and finally uses the derived key to decrypt the data stored on the device.

The authors claim three security properties: (1) anonymity, because the only values observable by an eavesdropper are the public‑key encrypted component C x and hash outputs; without the server’s private key the attacker cannot recover x or D ID, thus the device’s identity remains hidden. (2) Replay‑attack resistance, achieved by the use of one‑time random numbers D r and new r that are refreshed after each successful authentication, making any captured transcript useless for a later session. (3) Interactive identification, meaning that both the server and the device authenticate each other: the server validates the device’s D ID and DSig, while the device validates the server’s freshly generated hash and DSig.

While the protocol’s high‑level design is straightforward, the paper suffers from several critical shortcomings. First, the notation is inconsistent and many variables (e.g., the exact encryption algorithm for C x, key lengths, hash output size) are not formally defined, which would impede a concrete implementation. Second, the security proofs are informal; they rely on intuitive arguments rather than a rigorous game‑based model (e.g., IND‑CPA, EU‑F‑CMA) or a formal verification tool such as ProVerif. Third, the broker is assumed to be a trustworthy relay; no mechanism is provided to protect against a malicious broker that could launch man‑in‑the‑middle attacks or replay messages before the server updates its random values. Fourth, the storage and protection of the server‑side random numbers (D r, new r) and device signatures are not discussed; compromise of the server database would expose all device identifiers and potentially enable large‑scale attacks. Fifth, the choice of PBKDF2 parameters (iteration count c, derived key length dkLen) is left unspecified, which raises concerns about both computational overhead on constrained devices and resistance to brute‑force attacks.

The paper also lacks an empirical performance evaluation. No timing measurements are provided for the public‑key encryption, hash calculations, or PBKDF2 derivation on typical RFID or USB microcontrollers, making it impossible to assess whether the protocol meets real‑world latency and power constraints. Moreover, the authors do not compare their scheme against existing RFID authentication protocols (e.g., ISO/IEC 14443, EPCglobal Class‑1 Gen‑2, or recent lightweight group‑signature based solutions) in terms of communication overhead, storage requirements, or scalability.

In the discussion, the authors assert that the protocol “ensures anonymity” while still relying on a unique device identifier D ID that is known to the server. Consequently, the server can still track a device across sessions, which may be undesirable in privacy‑sensitive applications. To achieve true anonymity, additional techniques such as pseudonym rotation, group signatures, or zero‑knowledge proofs would be necessary.

In conclusion, the paper introduces a conceptually simple protocol that combines asymmetric encryption, hash‑based one‑time challenges, and PBKDF2‑derived symmetric keys to provide mutual authentication and secure key distribution for mobile secure devices. However, the lack of precise mathematical definitions, rigorous security analysis, implementation details, and performance results limits its contribution to the academic literature. Future work should focus on formal security modeling, resistance to malicious brokers, detailed parameter selection, and extensive experimental validation on actual hardware platforms.