Secure PKI Communications for "Machine-to-Machine" Modules, including Key Derivation by Modules and Authenticating Public Keys

• US 20150095648A1
• Filed: 09/27/2013
• Published: 04/02/2015
• Est. Priority Date: 09/10/2013
• Status: Active Grant

• Current Assignee: John A. Nix
• Original Assignee: M2M and IoT Technologies LLC
• Inventors: Nix, John A.
• Granted Patent: US 9,288,059 B2
• Time in Patent Office: Days
• US Class Current: 713/170
• CPC Class Codes: G06F 21/35 communicating wirelessly
• CPC Class Codes: G06F 21/445 by mutual authentication, e.g. between devices or programs
• CPC Class Codes: G06F 2221/2105 Dual mode as a secondary aspect
• CPC Class Codes: G06F 2221/2107 File encryption
• CPC Class Codes: G06F 2221/2115 Third party
• CPC Class Codes: H04J 11/00 Orthogonal multiplex systems, e.g. using WALSH codesH04J13/00 takes precedence
• CPC Class Codes: H04L 12/2854 Wide area networks, e.g. public data networks
• CPC Class Codes: H04L 2209/24 Key scheduling, i.e. generating round keys or sub-keys for block encryption
• CPC Class Codes: H04L 2209/72 Signcrypting, i.e. digital signing and encrypting simultaneously
• CPC Class Codes: H04L 2209/805 Lightweight hardware, e.g. radio-frequency identification [RFID] or sensor
• CPC Class Codes: H04L 63/0272 Virtual private networks
• CPC Class Codes: H04L 63/0435 wherein the sending and receiving network entities apply symmetric encryption, i.e. same key used for encryption and decryption cryptographic mechanisms or cryptographic arrangements for symmetric key encryption H04L9/06
• CPC Class Codes: H04L 63/0442 wherein the sending and receiving network entities apply asymmetric encryption, i.e. different keys for encryption and decryption cryptographic mechanisms or cryptographic arrangements for public-key encryption H04L9/30
• CPC Class Codes: H04L 63/045 wherein the sending and receiving network entities apply hybrid encryption, i.e. combination of symmetric and asymmetric encryption cryptographic mechanisms or cryptographic arrangements using a plurality of keys or algorithms H04L9/14
• CPC Class Codes: H04L 63/0464 using hop-by-hop encryption, i.e. wherein an intermediate entity decrypts the information and re-encrypts it before forwarding it
• CPC Class Codes: H04L 63/061 for key exchange, e.g. in peer-to-peer networks cryptographic mechanisms or cryptographic arrangements for key agreement H04L9/0838
• CPC Class Codes: H04L 63/0807 using tickets, e.g. Kerberos cryptographic mechanisms or cryptographic arrangements for entity authentication using tickets or tokens H04L9/3213
• CPC Class Codes: H04L 63/123 received data contents, e.g. message integrity
• CPC Class Codes: H04L 63/166 at the transport layer
• CPC Class Codes: H04L 67/04 specially adapted for terminals or networks with limited capabilities; specially adapted for terminal portability
• CPC Class Codes: H04L 9/006 : involving public key infrastructure [PKI] trust models network architecture or network communication protocol for supporting authentication of entities using certificates in a packet data network H04L63/0823
• CPC Class Codes: H04L 9/0816 : Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
• CPC Class Codes: H04L 9/0841 : involving Diffie-Hellman or related key agreement protocols
• CPC Class Codes: H04L 9/085 : Secret sharing or secret splitting, e.g. threshold schemes
• CPC Class Codes: H04L 9/0861 : Generation of secret information including derivation or calculation of cryptographic keys or passwords
• CPC Class Codes: H04L 9/088 : Usage controlling of secret information, e.g. techniques for restricting cryptographic keys to pre-authorized uses, different access levels, validity of crypto-period, different key- or password length, or different strong and weak cryptographic algorithms network architectures or network communication protocols for using time-dependent keys in a packet data network H04L63/068
• CPC Class Codes: H04L 9/0894 : Escrow, recovery or storing of secret information, e.g. secret key escrow or cryptographic key storage
• CPC Class Codes: H04L 9/14 : using a plurality of keys or algorithms
• CPC Class Codes: H04L 9/30 : Public key, i.e. encryption algorithm being computationally infeasible to invert or user's encryption keys not requiring secrecy
• CPC Class Codes: H04L 9/3066 : involving algebraic varieties, e.g. elliptic or hyper-elliptic curves
• CPC Class Codes: H04L 9/32 : including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
• CPC Class Codes: H04L 9/321 : involving a third party or a trusted authority
• CPC Class Codes: H04L 9/3239 : involving non-keyed hash functions, e.g. modification detection codes [MDCs], MD5, SHA or RIPEMD
• CPC Class Codes: H04L 9/3247 : involving digital signatures
• CPC Class Codes: H04L 9/3249 : using RSA or related signature schemes, e.g. Rabin scheme
• CPC Class Codes: H04L 9/3263 : involving certificates, e.g. public key certificate [PKC] or attribute certificate [AC]; Public key infrastructure [PKI] arrangements network architectures or network communication protocols for supporting authentication of entities using certificates in a packet data network H04L63/0823
• CPC Class Codes: H04W 12/02 : Protecting privacy or anonymity, e.g. protecting personally identifiable information [PII]
• CPC Class Codes: H04W 12/033 : of the user plane, e.g. user's traffic
• CPC Class Codes: H04W 12/04 : Key management, e.g. using generic bootstrapping architecture [GBA]
• CPC Class Codes: H04W 12/06 : Authentication
• CPC Class Codes: H04W 12/069 : using certificates or pre-shared keys
• CPC Class Codes: H04W 12/40 : Security arrangements using identity modules
• CPC Class Codes: H04W 4/70 : Services for machine-to-machine communication [M2M] or machine type communication [MTC]
• CPC Class Codes: H04W 40/005 : Routing actions in the presence of nodes in sleep or doze mode
• CPC Class Codes: H04W 52/0216 : using a pre-established activity schedule, e.g. traffic indication frame
• CPC Class Codes: H04W 52/0235 : where the received signal is a power saving command
• CPC Class Codes: H04W 52/0277 : according to available power supply, e.g. switching off when a low battery condition is detected
• CPC Class Codes: H04W 76/27 : Transitions between radio resource control [RRC] states
• CPC Class Codes: H04W 8/082 : for traffic bypassing of mobility servers, e.g. location registers, home PLMNs or home agents
• CPC Class Codes: H04W 80/04 : Network layer protocols, e.g. mobile IP [Internet Protocol]
• CPC Class Codes: H04W 84/12 : WLAN [Wireless Local Area Networks]
• CPC Class Codes: H04W 88/12 : Access point controller devices
• CPC Class Codes: Y02D 30/70 : in wireless communication networks

Abstract

Methods and systems are provided for efficient and secure “Machine-to-Machine” (M2M) between modules and servers. A module can communicate with a server by accessing the Internet, and the module can include a sensor and/or actuator. The module and server can utilize public key infrastructure (PKI) such as public keys to encrypt messages. The module and server can use private keys to generate digital signatures for datagrams sent and decrypt messages received. The module can internally derive pairs of private/public keys using cryptographic algorithms and a set of parameters. A server can use a shared secret key to authenticate the submission of derived public keys with an associated module identity. For the very first submission of a public key derived the module, the shared secret key can comprise a pre-shared secret key which can be loaded into the module using a pre-shared secret key code.

Claims

1. A method for a module to use a public key and a private key, the method comprising the module:

deriving the private key and the public key using a cryptographic algorithms, wherein the module records the private key in a nonvolatile memory;

reading (i) a module identity using a read-only address in the module, and (ii) a shared secret key from the nonvolatile memory;

sending a first message, wherein the first message includes the public key, a set of parameters for the public key, and the module identity, and wherein the module uses the shared secret key to authenticate the first message;

sending a second message, wherein the second message includes a module encrypted data, the module identity, and a module digital signature, wherein the module encrypted date (i) is ciphered using an asymmetric ciphering algorithm and (ii) includes a value for a symmetric key, and wherein the module digital signature is processed using the private key;

receiving a response, wherein the response includes a server encrypted data, and wherein the server encrypted data includes a module instruction, and wherein the server encrypted data is decrypted using the symmetric key;

2. The method of claim 1, further comprising the module using an elliptic curve cryptography ECC algorithm for deriving the public key, wherein the symmetric key is derived using the module public key, a server public key, and a key derivation function.

3. The method of claim 1, wherein the set of parameters includes at least two of an elliptic curve name for an ECC algorithm, a modulus for using an RSA algorithm, a validity date for the public key, a supported point formats extension, a module public key identity, and wherein the elliptic curve name comprises at least one name from an elliptic curve in (i) ANSI X9.63 and (ii) FIPS 186-2.

4. The method of claim 1, wherein the shared secret key comprises a pre-shared secret key, wherein the pre-shared secret key is obtained by entering a pre-shared secret key code into a web page, and wherein the pre-shared secret key is loaded into non-volatile memory by at least one of a distributor, installer, and end-user associated with the module.

5. The method of claim 1, wherein the module derives the shared secret key using (i) a key derivation function, (ii) a server public key, and (iii) a previous module private key, and wherein the previous module private key was recorded in non-volatile memory before the module derives the private key.

6. The method of claim 1, wherein the first message, the second message, and the response each comprise a user datagram protocol (UDP) packet, wherein the first message and the second message are sent to an IP address and port (IP:

port) number, and wherein the response is received from the IP;

port number.

7. The method of claim 1, further comprising the module sending a detach message to a wireless network (i) after receiving the response, and (iii) before sending a third message, wherein the module enters a dormant state after sending the detach message.

8. The method of claim 1, wherein the module authenticates using the shared secret key and at least one of (i) a message digest algorithm, (ii) a symmetric ciphering algorithm that ciphers using the shared secret key, and (iii) a digital signature algorithm that uses the shared secret key.

9. The method of claim 1, wherein the module derives the private key using a random number generator, and wherein the module inputs into the random number generator at least two of a sensor measurement, a radio measurement, a clock time, a state within an operating system, a state from memory, and a value output from a secure hash algorithm.

10. The method of claim 1, wherein the module instruction comprises an instruction for the module to derive an additional set of keys, wherein the module derives the additional set of keys using the cryptographic algorithms and the set of parameters, and wherein the additional set of keys are utilized to authenticate the module with a wireless network.

11. A method for a server to receive a sensor measurement, the method comprising:

receiving a first message that includes a module identity, a module public key, and a set of parameters, wherein the first message is authenticated using a shared secret key;

receiving a second message that includes the module identity, a module encrypted data, and a module digital signature, wherein the module encrypted data (i) includes the sensor measurement and (ii) is decrypted using a private key;

using the module identity received in the second message to select the module public key, wherein the module digital signature is verified using the selected module public key;

encrypting a module instruction using the selected module public key;

sending a response to the second message, wherein the response includes a server encrypted data, wherein the server encrypted data includes the encrypted module instruction.

12. The method of claim 11, wherein, after authentication using the shared secret key, the sever generates a certificate using the module identity, the set of parameters, and the module public key, wherein at least one of an organizational unit (OU) and a common name (CN) field in the certificate includes the module identity, and wherein the CN field includes a module public key identity.

13. The method of claim 11, wherein the module encrypted data includes a value for a symmetric key, and wherein the server encrypted data is ciphered using (i) a symmetric ciphering algorithm and (ii) the symmetric key, and wherein the response includes a server digital signature.

14. The method of claim 11, further comprising

sending an updated shared secret key;

receiving a third message that includes the module identity, an updated module public key, and an updated set of parameters, wherein the third message is authenticated using the updated shared secret key.

15. The method of claim 11, wherein the set of parameters includes at least two of an elliptic curve name for an ECC algorithm, a modulus for using an RSA algorithm, a validity date for the public key, a supported point formats extension, a module public key identity, and wherein the elliptic curve name comprises at least one name from an elliptic curve in (i) ANSI X9.63 and (ii) FIPS 186-2.

16. The method of claim 11, wherein a module sends the first and second message, wherein the shared secret key comprises a pre-shared secret key, wherein the pre-shared secret key is obtained by entering a pre-shared secret key code into a web page, and wherein the pre-shared secret key is loaded into non-volatile memory of the module by at least one of a distributor, installer, and end-user associated with the module.

17. The method of claim 11, further comprising deriving the shared secret key using (i) a key derivation function, (ii) a server public key, and (iii) a previous module public key, wherein the previous module public key was recorded in a database before receiving the first message.

18. The method of claim 11, wherein the second message and the response each comprise a user datagram protocol (UDP) packet, wherein the first message was received from an IP address and port (IP:

port) number, and wherein the response is sent to the IP;

port number.

19. A method for a module to use a public key and a private key, the method comprising the module:

deriving the private key and the public key using a cryptographic algorithms, wherein the module records the private key in a nonvolatile memory;

reading (i) a module identity using a read-only address in the module, and (ii) a shared secret key from the nonvolatile memory;

sending a first message, wherein the first message includes the module identity, a set of parameters, and a first module encrypted data, wherein the first module encrypted data includes the public key, and wherein the first module encrypted data is encrypted using (a) a symmetric ciphering algorithm and (b) the shared secret key;

sending a second message, wherein the second message includes a second module encrypted data and the module identity, wherein the second module encrypted data (i) includes a sensor measurement and (ii) is encrypted using a symmetric key, wherein the public key is used to process the symmetric key;

receiving a response, wherein the response includes a server encrypted data, and wherein the server encrypted data includes a module instruction, and wherein the server encrypted data is decrypted using the symmetric key;

20. The method of claim 19, further comprising the module using an elliptic curve cryptography ECC algorithm for deriving the public key, wherein the symmetric key is derived using the module public key, a server public key, and a key derivation function.

21. The method of claim 19, wherein the set of parameters includes at least two of an elliptic curve name for an ECC algorithm, a modulus for using an RSA algorithm, a validity date for the public key, a supported point formats extension, a module public key identity, and wherein the elliptic curve name comprises at least one name from an elliptic curve in (i) ANSI X9.63 and (ii) FIPS 186-2.

22. The method of claim 19, wherein the shared secret key comprises a pre-shared secret key, wherein the pre-shared secret key is obtained by entering a pre-shared secret key code into a web page, and wherein the pre-shared secret key is loaded into non-volatile memory by at least one of a distributor, installer, and end-user associated with the module.

23. The method of claim 19, wherein the module derives the shared secret key using (i) a key derivation function, (ii) a server public key, and (iii) a previous module private key, and wherein the previous module private key was recorded in non-volatile memory before the module derives the private key.

24. The method of claim 19, wherein the first message, the second message, and the response each comprise a user datagram protocol (UDP) packet, wherein the first message and the second message are sent to an IP address and port (IP:

port) number, and wherein the response is received from the IP;

port number.

25. The method of claim 24, wherein the UDP packet is formatted using a UDP Lite protocol, and wherein the UDP packet includes a channel coding.

26. The method of claim 19, further comprising the module sending a detach message to a wireless network (i) after receiving the response, and (ii) before sending a third message, wherein the module enters a dormant state after sending the detach message.

27. The method of claim 19, wherein the module derives the private key using a random number generator, and wherein the module inputs into the random number generator at least three of a sensor measurement, a radio measurement, a clock time, a state within an operating system, a state from memory, and a value output from a secure hash algorithm.