Secure PKI communications for “machine-to-machine” modules, including key derivation by modules and authenticating public keys

• US 9,288,059 B2
• Filed: 09/27/2013
• Issued: 03/15/2016
• 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.
• Primary Examiner(s): Tran, Ellen
• Assistant Examiner(s): Nipa, Wasika
• Application Number:
  US14/039,401
• Publication Number:
  US 20150095648A1
• Time in Patent Office: 900 Days
• US Class Current: 1/1
• 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: H05K 999/99 : dummy group
• 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 hardware module with a radio to use a public key and a private key, the method performed by the hardware module, the method comprising:

receiving a set of parameters, wherein the set of parameters includes a value for an elliptic curve and a key length;

deriving the private key and the public key using a key pair generation algorithm with the received set of parameters, wherein the hardware module records the derived private key in a nonvolatile memory, wherein the derived private key is used at least, in part, for processing a module digital signature, and wherein the hardware module authenticates with the module digital signature;

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

transmitting via the radio a first message, wherein the first message includes the derived public key, a module public key identity and the module identity, and wherein the hardware module uses the shared secret key to authenticate the first message;

transmitting via the radio a second message from an interne protocol address and port (IP;

port) number, wherein the second message includes a module encrypted data, the module identity, and the module digital signature, wherein the module encrypted data (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 derived private key; and

,

receiving via the radio a response at the IP;

port number, 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 hardware module using an elliptic curve cryptography (ECC) algorithm for deriving the public key, wherein the private key is derived using a random number generator, and wherein the random number generator uses a measurement from a sensor.

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, and a module public key identity, and wherein the elliptic curve name comprises at least one elliptic curve name from (i) American National Standards Institute (ANSI) standard X9.63 and (ii) Federal Information Processing Standard (FIPS) publication 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 receiving 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 hardware module.

5. The method of claim 1, wherein the hardware 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 the non-volatile memory before the hardware 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.

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

8. The method of claim 1, wherein the hardware module authenticates the first message 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 hardware module derives the private key using a random number generator, and wherein the hardware 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 hardware module to derive an additional set of keys, wherein the hardware module derives the additional set of keys using a set of cryptographic algorithms and the set of parameters, and wherein the additional set of keys are utilized to authenticate the hardware module with a wireless network.

11. A method for a server to receive a sensor measurement through a local area network (LAN) interface, the server including at least one computer processor for performing the steps of the method, the method comprising:

recording (i) a module identity for a module and (ii) a shared secret key;

sending via the LAN interface (i) a set of parameters for deriving a module public key and a module private key, (ii) a first security token, and (iii) a first server digital signature, wherein the set of parameters includes a value for an elliptic curve and a key length, wherein the first server digital signature uses the first security token as a first nonce;

receiving via the LAN interface a first message from a module that includes the module identity, the module public key derived from the set of parameters, and the first security token, wherein the server uses the module identity to select the shared secret key from a database, and wherein the first message is authenticated using the selected shared secret key;

receiving at a port number with the LAN interface a second message from the module that includes the module identity, a module encrypted data, a second security token, and a module digital signature, wherein the module encrypted data (i) includes the sensor measurement and (ii) is decrypted using a private key for the server, wherein the module digital signature uses the second security token as a second nonce;

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; and

,

sending from the port number with the LAN interface to the module a response to the second message, wherein the response includes a server encrypted data and a second server digital signature, wherein the server encrypted data includes the encrypted module instruction, and wherein the second server digital signature uses the second security token.

12. The method of claim 11, wherein, after authenticating the first message using the selected shared secret key, the server 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.

14. The method of claim 11, further comprising:

sending an updated shared secret key; and

,

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, and a module public key identity, and wherein the elliptic curve name comprises at least one elliptic curve name in (i) ANSI standard X9.63 and (ii) FIPS publication 186-2.

16. The method of claim 11, wherein the 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 a source IP address and port (IP:

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

port number.

19. A method for a hardware module with a radio to use a public key and a private key, the method performed by the hardware module, the method comprising:

receiving a set of parameters, wherein the set of parameters includes a value for an elliptic curve and a key length;

deriving the private key and the public key using (i) a key pair generation algorithm with the received set of parameters, wherein the hardware module records the derived private key in a nonvolatile memory, wherein the derived private key is used at least, in part, for processing a module digital signature, and wherein the hardware module authenticates with the module digital signature;

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

transmitting via the radio a first message, wherein the first message includes the identity 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;

transmitting via the radio a second message from an interne protocol address and port (IP;

port) number, 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; and

,

receiving via the radio a response at the IP;

port number, 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 hardware module using an elliptic curve cryptography ECC algorithm for deriving the public key, wherein the private key is derived using a random number generator, and wherein the random number generator uses a measurement from a sensor.

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, and a module public key identity, and wherein the elliptic curve name comprises at least one elliptic curve name in (i) ANSI standard X9.63 and (ii) FIPS publication 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 hardware module.

23. The method of claim 19, wherein the hardware 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 hardware 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 a destination IP address and port (IP:

port) number, and wherein the response is received from the destination 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 hardware module sending a detach message to a wireless network (i) after receiving the response, and (ii) before sending a third message, wherein the hardware module enters a dormant state after sending the detach message.

27. The method of claim 19, wherein the hardware module derives the private key using a random number generator, and wherein the hardware 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.