Set of servers for “machine-to-machine” communications using public key infrastructure

• US 9,596,078 B2
• Filed: 07/01/2015
• Issued: 03/14/2017
• 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): LESNIEWSKI, VICTOR D
• Application Number:
  US14/789,255
• Publication Number:
  US 20150304113A1
• Time in Patent Office: 622 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

A set of servers can support secure and efficient “Machine to Machine” communications using an application interface and a module controller. The set of servers can record data for a plurality of modules in a shared module database. The set of servers can (i) access the Internet to communicate with a module using a module identity, (i) receive server instructions, and (iii) send module instructions. Data can be encrypted and decrypted using a set of cryptographic algorithms and a set of cryptographic parameters. The set of servers can (i) receive a module public key with a module identity, (ii) authenticate the module public key, and (iii) receive a subsequent series of module public keys derived by the module with a module identity. The application interface can use a first server private key and the module controller can use a second server private key.

Claims

1. A method for supporting machine-to-machine communications, the method performed by a set of servers using at least one computer processor, the method comprising:

recording a first server private key in a nonvolatile memory, wherein the first server private key is used to establish a secure connection with an application server;

receiving a message through at least one local area network (LAN) interface, wherein the message includes a module identity and a module digital signature, wherein the module digital signature is verified using a first module public key, and wherein the message includes a first source Internet protocol address and port (IP;

port) number;

transmitting a response to the first source IP;

port number, wherein the response includes a server digital signature processed using a second server private key;

using the module identity to select from a module database a set of cryptographic parameters for processing a second module public key;

transmitting the set of cryptographic parameters;

receiving the second module public key and the module identity, wherein at least one member of the set of servers processes the second module public key using (i) the module identity and (ii) at least a portion of the set of cryptographic parameters, wherein the second module public key is verified using the first module public key, wherein the second module public key is used to decrypt a module encrypted data, and wherein the module encrypted data includes a sensor data; and

transmitting the sensor data and the module identity to the application server using the secure connection.

2. The method of claim 1, wherein the module identity in the first message comprises a first string, and wherein the module identity sent with the sensor data comprises a second string, and wherein the first string and the second string are associated with a serial number of a module.

3. The method of claim 1, wherein the set of servers includes at least a first server and a second server, wherein (i) the first server receives the message and transmits the response, and (ii) the second server receives the module encrypted data, wherein the set of servers includes a shared module database, and wherein the shared module database records the module identity, the first module public key, and the second module public key.

4. The method of claim 1, wherein the set of cryptographic parameters includes at least one of (i) an elliptic curve cryptography (ECC) named curve, (ii) a value for an ECC defining equation, (iii) a modulus for an RSA algorithm, (iv) a time-to-live value, (v) a value for a random number seed, (vi) a value for a module public key identity, or (vii) a value for a module random seed file.

5. The method of claim 1, wherein a module using the module identity sends the message and the second module public key, and wherein the module derives the second module public key using at least a set of cryptographic algorithms and the set of cryptographic parameters, and wherein the module sends a digital signature with the second module public key, wherein the digital signature is processed using a first module private key, wherein a second module private key is associated with the second module public key, and wherein the first module private key and the second module private key are different.

6. The method of claim 5, wherein the module includes an embedded universal integrated circuit card (eUICC), wherein the eUICC records a module private key associated with the first module public key, and wherein the set of servers records the first module public key and the module identity.

7. The method of claim 1, wherein the first and second server private keys are different, wherein the first server private key is processed using an RSA algorithm and the second server private key is processed using an ECC algorithm.

8. The method of claim 1, further comprising:

receiving a module instruction and the module identity; and

sending the module instruction within a server encrypted data after receiving a third message that includes the module identity, wherein the server encrypted data is ciphered using the second module public key.

9. The method of claim 1, wherein decrypting the module encrypted data using the second module public key further comprises:

decrypting the module encrypted data with a symmetric key, and at least one of (i) sending the symmetric key using an asymmetric ciphering algorithm and the second module public key, (ii) deriving the symmetric key using a key derivation function and the second module public key, or (iii) receiving (a) the symmetric key using an asymmetric ciphering algorithm and (b) a digital signature, wherein the digital signature is verified using the second module public key, wherein the symmetric key with the module identity are recorded in the module database, and wherein the symmetric key is processed using the set of cryptographic parameters selected from the module database using the module identity.

10. The method of claim 1, wherein verifying the second module public key using the first module public key comprises at least one of (i) receiving the second module public key with a digital signature, wherein the digital signature is processed with the first module public key, or (ii) receiving an encrypted data with the second module public key, wherein the encrypted data is decrypted using the first module public key.

11. A system for supporting machine-to-machine communications, the system comprising:

a module controller for;

monitoring a destination Internet protocol address and port (IP;

port) number,

receiving, from a module behind a firewall, a first message comprising a module identity of the module and a first source IP;

port number of the module, wherein the module identity is verified using a first module public key,

sending to the module at the first source IP;

port number a set of cryptographic parameters for deriving a public and private key pair,

receiving, from the module, a second message comprising a second module public key and the module identity, the second module public key being of a public and private key pair derived from the cryptographic parameters, wherein the second message is verified using the first module public key,

receiving, from the module reconnected from behind the firewall, a third message comprising the module identity of the module and a second source IP;

port number of the module, wherein the first and second source IP;

port numbers are different, and

sending a response to the third message from the destination IP;

port number to the module at the second source IP;

port number, wherein the response includes an encrypted module instruction, wherein the encrypted module instruction is ciphered using the second module public key, and wherein the module controller sends the response after receiving the second message;

an application interface for using a first server private key to receive the module instruction;

a module database for recording the module identity and the set of cryptographic parameters, and for sending the set of cryptographic parameters to the module controller in response to a query including the module identity; and

,

a processor for using a second server private key and the set of cryptographic parameters to calculate a server digital signature, wherein the server digital signature is sent from the destination IP;

port number.

12. The system of claim 11, wherein the module using the module identity sends the first, second, and third messages, wherein the module includes a set of cryptographic algorithms to derive (i) the first module public key and a first module private key and (ii) the second module public key and a second module private key, and wherein (i) after receiving the first message, and (ii) before receiving the second message, the module controller sends an instruction for the module to derive the second module public key.

13. The system of claim 11, wherein the first module public key is verified using a shared secret key and at least one of (i) a message digest algorithm, (ii) a module digital signature, wherein the module digital signature was processed using the shared secret key, or (iii) a symmetric ciphering algorithm, wherein the symmetric ciphering algorithm uses the shared secret key.

14. The system of claim 11, further comprising a set of cryptographic algorithms for using (i) a first server public key with the application interface, and (ii) a second server public key with the module controller, wherein the first server public key is associated with an RSA algorithm, and wherein the second public key is associated with an elliptic curve cryptography (ECC) algorithm.

15. The system of claim 11, wherein the set of cryptographic parameters includes at least one of (i) an elliptic curve cryptography (ECC) named curve, (ii) a value for an ECC defining equation, (iii) a modulus for an RSA algorithm, (iv) a time-to-live value, or (v) a value for a module public key identity, and wherein the first message comprises a first series of datagrams, and the second message comprises a second series of datagrams.

16. The system of claim 11, wherein the third message includes a server instruction, wherein the server instruction is received in a module encrypted data, wherein the module encrypted data includes a security token, and at least one of a sensor measurement, a registration message, or an acknowledgement, and wherein the module encrypted data is processed using the set of cryptographic parameters.

17. The system of claim 11, further comprising the module controller for receiving a series of different module public keys with the module identity after receiving the first message, wherein each of the different module public keys in the series is verified using a prior module public key in the series.

18. A method for supporting machine-to-machine communications, the method performed by a set of servers using at least one computer processor, the method comprising:

receiving, from a module, a first message that includes a module identity of the module and a first source Internet protocol address and port (IP;

port) number associated with the module, wherein the module identity is verified using a first module public key;

transmitting a query to a module database and receiving a response from the module database, wherein the query includes the module identity, and wherein the response includes at least a set of cryptographic parameters for deriving a public and private key pair;

transmitting a response to the module at the first source IP;

port number, wherein the response includes at least a portion of the set of cryptographic parameters;

receiving, from the module, a second message which includes a second module public key and the module identity, the second module public key being of a public and private key pair derived from the cryptographic parameters, wherein the second message is verified using the first module public key;

receiving, from an application server, via a secure connection, a module instruction and the module identity;

receiving, from the module, a third message, wherein the third message includes (i) a second source IP;

port number associated with the module and (ii) the module identity; and

transmitting the module instruction within a server encrypted data to the module at the second source IP;

port number, wherein the server encrypted data is ciphered using the second module public key, and wherein the first and second source IP;

port numbers are different.

19. The method of claim 18, wherein the set of cryptographic parameters includes at least one of (i) an elliptic curve cryptography (ECC) named curve, (ii) a value for an ECC defining equation, (iii) a modulus for an RSA algorithm, (iv) a time-to-live value, (v) a value for a random number seed, (vi) a value for a module public key identity, or (vii) a value for a module random seed file, and wherein the first message comprises a first series of datagrams, the second message comprises a second series of datagrams.

20. The method of claim 18, wherein the first module public key comprises a first address for the first module public key, and wherein the second module public key comprises a second address for the second module public key.

21. The method of claim 18, wherein the set of servers includes at least a first server and a second server, wherein the first server receives the first message and the second server receives the second message, wherein the set of servers includes the module database, wherein the module database records the module instruction received from the application server, wherein the second server queries the module database for the module instruction after receiving the second message, and wherein the set of servers receives a series of public keys from the module after receiving the first message.

22. The method of claim 18, wherein the module with the module identity sends (i) the first and the second messages, and (ii) the first and second module public keys, and wherein the module derives the second module public key using at least a set of cryptographic algorithms and the set of cryptographic parameters, and wherein the first and second module public key are different.

23. The method of claim 18, wherein the module includes an embedded universal integrated circuit card (eUICC), wherein the eUICC records an initial module private key, wherein the set of servers records an initial module public key and uses the initial module public key to verify the module identity and the first module public key, and wherein the eUICC uses the initial module private key to verify the module identity and the first module public key with the set of servers.

24. The method of claim 18, further comprising:

receiving the module instruction from an application server;

decrypting the module instruction using a first server private key, wherein the first server private key is processed using an RSA algorithm; and

ciphering the server encrypted data using a second server private key, wherein the second server private key is processed using an ECC algorithm.

25. The method of claim 18, wherein verifying the second message using the first module public key comprises authenticating a module digital signature in the second message, wherein the module digital signature is processed by the module using a first module private key, wherein the first module private key is different than a second module private key being of the public and private key pair derived from the cryptographic parameters, and wherein the first module private key comprises a secret key for the first module public key.

26. The method of claim 18, wherein ciphering the server encrypted data using the second module public key further comprises ciphering the server encrypted data with a symmetric key, wherein the symmetric key is shared by using at least one of (i) the second module public key and a key derivation function, (ii) an asymmetric ciphering algorithm and the second module public key to encrypt the symmetric key, wherein the set of servers transmits the symmetric key, or (iii) a digital signature verified with the second module public.

27. The method of claim 26, wherein the set of servers receives the symmetric key and the digital signature from the module, wherein the symmetric key with the module identity are recorded in the module database, and wherein the symmetric key is processed using the set of cryptographic parameters selected from the module database using the module identity.