WO2019102239A1 - Method for ensuring secure and authorized communications between a first device and a second device - Google Patents

Method for ensuring secure and authorized communications between a first device and a second device Download PDF

Info

Publication number
WO2019102239A1
WO2019102239A1 PCT/HU2018/050048 HU2018050048W WO2019102239A1 WO 2019102239 A1 WO2019102239 A1 WO 2019102239A1 HU 2018050048 W HU2018050048 W HU 2018050048W WO 2019102239 A1 WO2019102239 A1 WO 2019102239A1
Authority
WO
WIPO (PCT)
Prior art keywords
command
data
secure element
verifying
user
Prior art date
Application number
PCT/HU2018/050048
Other languages
French (fr)
Inventor
András VILMOS
Original Assignee
Vilmos Andras
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Vilmos Andras filed Critical Vilmos Andras
Publication of WO2019102239A1 publication Critical patent/WO2019102239A1/en
Priority to US15/931,313 priority Critical patent/US11245523B2/en

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/12—Applying verification of the received information
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/02—Network architectures or network communication protocols for network security for separating internal from external traffic, e.g. firewalls
    • H04L63/0281—Proxies
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols 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
    • H04L9/3247—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols 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 involving digital signatures
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0853—Network architectures or network communication protocols for network security for authentication of entities using an additional device, e.g. smartcard, SIM or a different communication terminal
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0884—Network architectures or network communication protocols for network security for authentication of entities by delegation of authentication, e.g. a proxy authenticates an entity to be authenticated on behalf of this entity vis-à-vis an authentication entity
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/10—Network architectures or network communication protocols for network security for controlling access to devices or network resources

Definitions

  • the present invention relates to a method for ensuring secure and authorized communications between a first device and a second device.
  • the present invention has for objective to overcome the problems associated with the prior art solutions.
  • the present invention has for objective to protect a remotely operable second device (which may even be a complex system as well) without the need to change anything on the device itself, with only slight modification of the application running on a remote first (client, user) device, which operates the second (secured, protected) device.
  • the inventor of the present invention proposes an economically sound approach to install an additional device, a secure gateway into the present communication channel between the first and second devices and provide the highest level of user and credential authentication and authorization. With the proposed solution even existing implementations can be upgraded to the highest security level with marginal expenses, without the need to modify the protected system. This way all that is needed is to integrate a secure element and some additional functions into the front-end management application, running on the first device.
  • Method for ensuring secure and authorized communications between a first device and a second device comprising: - providing a gateway system suitable for data communication with the first device via a first electronic communication channel and with the second device via a second electronic communication channel,
  • the gateway system receiving by the gateway system from the first device via the first electronic communication channel at least one data packet comprising at least one command executable by the second device and a data block containing at least command identification data of the at least one command, the data block being signed by the private key;
  • the term "at least one data packet comprising at least one command executable by the second device, and a data block containing at least command identification data of the at least one command, the data block being signed by the private key” is understood to have the meaning that the at least one command and the command identification data of the at least one command can be contained in a single data packet or can be contained in more than one data packets. In case more data packets are received by the gateway, the data packets are preferably linked to each other.
  • the method further comprises:
  • the first secure element is an embedded secure element in the first device, or a removable card (e.g. SIM card, SD card) of the first device, or an external smart card connectable to the first device, or a software application
  • the command identification data preferably comprises a command code associated with the command by the first device.
  • the command identification data preferably comprises a hash of the command, which hash is generated by the first device using a hash algorithm.
  • the user identification data is an identifier of the first secure element, such as Card Identification Number (CIN) of a smart card or a SIM card.
  • CIN Card Identification Number
  • the user identification data is based on the signature applied to the data block, for example the public key certificate corresponding to the private key.
  • Fig. 1 is a schematic block diagram of an exemplary embodiment of a system suitable for carrying out the method according to the invention.
  • Fig. 2 is a more detailed block diagram of certain element of Fig. 1.
  • Fig. 3a and 3b are flow diagrams illustrating the steps of an exemplary embodiment of the present invention.
  • Fig. 4a and 4b are flow diagrams illustrating the steps of another exemplary embodiment of the present invention.
  • Fig. 5a and 5b are flow diagrams illustrating the steps of another exemplary embodiment of the present invention.
  • the exemplary embodiment illustrated in Fig. 1 and Fig. 2 comprises a first client device 10 equipped with a secure element 20, a gateway system 30, a secured system 40 including at least one remotely controllable second device 42 and a Public key cryptography key pair 50 consisting of a private key 50a and a public key 50b.
  • the public key infrastructure may be based on any kind of cryptographic algorithms, including post-quantum cryptographic algorithms as well.
  • the client device 10 and the gateway system 30 are connectable via an electronic communication channel 60, which is preferably established over the Internet 62.
  • the client device 10 is a personal computer having a processor 11 , a data storage 12, a communication unit 13, a secure element interface 14, a display 15 and a user input interface 16 e.g. keyboard, touchscreen, mouse, etc.
  • client devices could be used as well, such as a smart phone, tablet, laptop, smart watch, etc. These devices have similar structure, accordingly the present description applies mutatis mutandis.
  • a program 12a for generating and sending operation commands to the remotely controllable second device 42 is stored in the data storage 12 of the computer 10.
  • the secure element 20 is a smart card 20a, which also comprises a processor 21 , a secure storage 22 (usually built together in one microcontroller) and a communication interface 23 for communicating with the client device 10 over the smart card interface 14.
  • the private key 50a is stored in the secure storage 22.
  • user authentication data 24 and user privileges data 25 are also stored in the secure storage 22.
  • Other types of secure elements 20 are also conceivable as will be apparent for a skilled person, for example an embedded secure element in the client device 10, a removable card (e.g. SIM card, SD card) of the client device 10, an external smart card connectable to the client device 10, a software application (e.g. Trusted Execution Environment) of the client device 10, or a secure storage facility in a cloud on a remote server.
  • the gateway system 30 comprises a gateway computer 32, which is a small computer having at least a processor 33, a data storage 34 and a communication unit 35.
  • the communication unit 13 of the client device 10 and the communication unit 35 of the gateway system 30 are connectable via the electronic communication channel 60.
  • the computer 32 is suitable for establishing the electronic communication channel 60 with the client device 10 over the Internet 62 in the form of a VPN connection (Virtual Private Network connection).
  • a user database 36 is provided and stored in the data storage 34 of the gateway computer 32.
  • the user database 36 may be stored at a remote location, which is accessible by the gateway system 30, in particular by the gateway computer 32.
  • the gateway system is preferably equipped with a secure element 70, which is preferably a smart card 70a connected to a smart card interface 37 of the gateway computer 32.
  • the secure element 70 comprises a processor 71 , a secure storage 72 and a communication interface 73 for communicating with the gateway computer 32 via the smart card interface 37.
  • the secure element 70 of the gateway system 30 may have various form factors or types, including, but not limited to SIM card, SD card, embedded secure element, trusted execution environment, external plastic card as well as remotely connected secure storage facility.
  • the public key 50b of the Public key cryptography key pair 50 is preferably stored in the secure storage 72 of the secure element 70 as illustrated in Fig. 2, however, it may also be stored in the data storage 34 of the gateway computer 32 or at a remote location, which is accessible by the gateway system 30.
  • Public keys are stored in the secure storage if it needs to be assured that only keys belonging to the system may be used. For this reason keys related to admin privileges and keys related to secure storage management privileges preferably are stored here. It should also be noted that for specific configurations (eg. when X.509 public key certificates are used) the public key 50b should not necessarily be stored at all in the gateway system 30 for the system to operate properly as it could also be received from the remote client device 10, during the communication. ln certain cases the user database 36 may also be stored in the secure storage 72 of the secure element 70 instead of the data storage 34 of the gateway computer 32.
  • the gateway system 30 preferably further comprises a firewall 38, which can be configured according to the privileges of the users of the system, and or according to the specifics of the secured system 40. Furthermore it may be configured to block any communication not corresponding to specific parameters.
  • the protected system 40 comprises a HUB 44 and a secured or hidden network 46 connecting two or more remotely controllable devices 42 with the HUB 44.
  • the HUB is also connected to the gateway system 30 such that all external communication has to pass through the gateway system 30.
  • the method according to the present invention is performed with the system schematically depicted in Figs. 1 and 2 as follows.
  • the user is assigned the smart card 20a, which is registered in the user database 36 of the gateway system 30.
  • the Public key cryptography key pair 50 is preferably generated in the smart card 20a and the private key 50a is stored in the secure storage 22 of the smart card 20a, while the public key 50b may be transmitted to the gateway system 30, where it can be stored in the secure storage 72 of the second smart card 70a.
  • User privileges are also assigned to the user and registered in the user database 36 in the data storage 34 of the gateway system 30.
  • Preferably some or all user privileges data 25 are transmitted to the smart card 20a as well, and stored in the secure storage 22 thereof.
  • step 100 the user authenticates himself by inputting via the input interface 16 of the client device 10 user authentication data.
  • the user is authenticated by the smart card 20a connected with the client device 10.
  • the smart card has a unique PIN 200 which the user needs to know and needs to input upon request to be able to perform any transaction with it.
  • Other type of user authentication data may be used as well, such as biometric identifiers.
  • the client device 10 is such a device which is typically used by a single user (e.g. a mobile phone), additionally a client device identifier 202 of the client device 10 (e.g.
  • a telephone number or serial number of the mobile phone, IMEI, or MAC address may also be used, or a special ID of the program 12a running on the client device 10 (e.g. registration ID) thereby linking the user to the client device 10 and/ or to a specific application as well, which increases the level of security.
  • step 102 a command 204 is generated for the remotely controllable second device 42 with the program 12a stored in the data storage 12 of the client device 10.
  • step 104 the program 12a generates command identification data 205 from the command 204.
  • the command identification data 205 is a command code 206.
  • the command code 206 is a short code derived from the command 204 and serving to identify the command 204.
  • the command for switching the light on may have a command code 206 such as "LON” and the command for switching the light off may have a command code 206 such as "LOFF”.
  • step 106 the user authentication data (unique PIN 200 and client device identifier 202) and the command identification data 205 are transmitted to the smart card 20a that is connected to the user device 10 via the smart card interface 14 of the client device 10.
  • the user authentication data and the command identification data 205 may be transmitted in separate steps as well.
  • step 108 the smart card 20a compares the received user authentication data with the user authentication data 24 stored in the secure storage 22 of the smart card 20a in order authenticate the user. If the user is successfully authenticated, the process continues, otherwise an error response or the like may be sent back to the client device 10.
  • step 110 the smart card 20a verifies the command code 206 by checking the user privileges data 25 stored in the secure storage 22 in order to determine whether or not the authenticated user has the necessary privileges to use the command 204 which is defined by the command code 206. If the authenticated user is allowed to transmit the command 204, which is defined by the command code 206, to the secured system 40 then the verification step is successful and the process continues, otherwise an error response or the like may be sent back to the client device 10.
  • step 112 the smart card 20a retrieves its CIN (card identification number) 210, in step 114 the smart card 20a generates a unique identifier 212 for the specific transaction, and in step 116 the smart card 20a generates a timestamp 214 too.
  • step 118 the command identification data 205, (which is now the command code 206), the CIN 210, the unique identifier 212 and the timestamp 214 are all concatenated in order to create a data block 216, which is then signed in step 120 by the smart card 20a using the private key 50a stored in its secure storage 22, whereby a signed data block 218 is obtained.
  • step 122 the signed data block 218 is transmitted back to the client device 10 via the communication interface 23 of the smart card 20a.
  • step 124 the client device generates a client data packet 220 containing the original command 204 and the signed data block 218.
  • step 126 the communication unit 13 of the client device 10 transmits the client data packet 220 to the gateway system 30 through the electronic communication channel 60 established over the Internet 62, which is preferably a VPN connection. It is also possible to send the original command 204 and the signed data block 218 in separate data packets, which are linked to each other e.g. by message identifiers.
  • the steps 104, 106, 124 and 126 may be performed by the program 12a itself, generating and sending operation commands 204 to the remotely controllable second device 42, stored in the data storage 12 of the client device 10, or may even be carried out by a second application dedicated for these functions and also forming a bridge between the program 12a and the secure element 20.
  • step 128 the client data packet is received by the gateway system 30 and the command 204 is separated from the signed data block 218.
  • the gateway system 30 checks whether or not the two data packets are linked to each other.
  • step 130 the gateway system 30 obtains user identification data from the user database 36 based on the signed data block 218 for identifying the public key 50b of the Public key cryptography key pair 50 of which the private key 50a has been used for signing the data block 216.
  • the user identification data is the CIN 210 contained in the signed data block 218, since the smart card 20a is assigned to the user.
  • the signature created by the unique private key 50a and applied to the data block 216 may also serve as the user identification data, when used with a PKI certificate.
  • a public key certificate may be sent by the smart card 20a together with the signed data block 218.
  • the public key 50b may also be stored in the client device 10, or the secure storage 22 of the smart card 20a thereof and not by the gateway system 30.
  • step 132 the gateway system verifies the integrity of the signed data block 218 by checking the signature of the signed data block 218 using the public key 50b. If the check fails it means that the data block has either been manipulated, or the client is not the one who it claims to be.
  • step 134 uniqueness of the command 204 is verified based on the unique identifier 212 contained in the signed data block 218: the gateway system 30 checks whether or not the unique identifier 212 has already been previously used, if yes the command 204 will not be forwarded to the second device 42 of the secured system 40.
  • step 136 expiration is verified based on the timestamp 214, current time and a pre-set expiry value, e.g. 10 minutes. The gateway system 30 checks whether or not the pre-set expiry value had already expired since the timestamp 214 was applied, if yes the command 204 will not be forwarded to the second device 42.
  • step 138 the user privileges of the user identified by the CIN 210 (or by the digital signature itself) are obtained from the user database 36 and verified in order to check the user's right to use the original command 204 based on the command code 206.
  • step 142 the gateway system checks whether the original command 204 received as part of the client data packet 220 corresponds to the command code 206 received. Verification may be done by performing a syntactic check of the command 204, or some kind of transformation of the original command 204 which should result in the command code 206 unless the original command 204 has been tampered.
  • step 140 the gateway system 30 regenerates a control command code 206' using the same code generation algorithm as used by the client device 10.
  • this control command code 206' is compared with the received first command code 206 to ensure that the command 204 has not been modified. Comparison is of course not required if the original command 204 has been modified in such a way that it is no longer possible to derive a control command code 206' therefrom. In such cases the request to transmit the command 204 can be declined without further verification.
  • the original command 204 is transmitted in step 144 by the gateway system 30 to the HUB 44 of the secured system 40 from where in step 146 it is routed over the secured or hidden network 46 to the second device 42 addressed by the command 204 to perform the function contained in the command 204.
  • Figs. 4a and 4b illustrate the steps of a second preferred embodiment.
  • the same reference numerals have been used for corresponding steps and entities. It will be appreciated that the order of the steps may differ from the order presented here. It has been realized that it is also possible to delegate much of the whole client credential control to the secure element 20 (smart card 20a) connected to the client device 10.
  • the program 12a running on the client device 10 generates in step 104 a first hash 208 of the command 204 and uses this information as the command identification data 205.
  • the first hash (digest) 208 of the command 204 is generated by the program 12a using a hash algorithm (e.g. SHA-256).
  • the first hash 208 is a compressed data obtained from the original command 204 which does not allow reconstruction of the original command 204. If the original command 204 is modified and the hash algorithm is applied to the modified command 204 this will result in a substantially different hash, whereby the first hash 208 can be used for tamper proofing as known in the art.
  • step 106 the user authentication data (unique PIN 200 and client device identifier 202) and the command identification data 205 (which is now the command hash 208) are transmitted to the smart card 20a that is connected to the user device 10 via the smart card interface 14 of the client device 10.
  • the user authentication data and the command identification data 205 may be transmitted in separate steps as well.
  • the smart card 20a verifies in step 110 the first hash 208 of the command 204 by checking the user privileges data 25 stored in the secure storage 22 in order to determine whether or not the authenticated user has necessary privileges to use the command 204 which is defined by the command hash 208. If the authenticated user is allowed to transmit the command 204, which is defined by the command hash 208, to the secured system 40 then the verification step is successful and the process continues, otherwise an error response or the like may be sent back to the client device 10.
  • step 138 i.e. verification of the user privileges may be omitted as the system fully trusts the verification performed by the secure element 20, connected to the client device 10.
  • the gateway In order to check that the same command 204 has been sent in the client data packet 220 as what has been verified in step 110 by the smart card 20a, the gateway generates a second hash 208' from the original command 204 in step 140 and compares it in step 142 with the first hash 208 received in the client data packet 220 to assure that the command 204 has not been manipulated and the user has the necessary privileges. After successful verification the original command 204 is transmitted in step 144 by the gateway system 30 to the HUB 44 of the secured system from where it is routed over the secured or hidden network 46 to the second device 42 addressed by the command 204 to perform the function contained in the command 204.
  • a further preferred embodiment illustrated in Figs. 5a and 5b combines the above described two embodiments by generating in step 104 both the command code 206 and the first hash 208 of the command 204 by the program 12a running on the client device 10 and using them together as the command identification data 205.
  • the user authentication data consists of the unique PIN 200 only, which is transmitted together with the command identification data 205 (consisting of the command code 206 and the command hash 208) in step 106 to the smart card 20a that is connected to the user device 10 via the smart card interface 14 of the client device 10.
  • the smart card 20a performs all the steps as described in the first embodiments but also includes the first hash 208 of the command 204 in the data block 216 which is then signed. From this point on all the steps performed by the smart card 20a, the program 12a on the client device 10 and the gateway system 30 are identical with what has been described in connection with the first embodiment until checking user privileges in step 138.
  • step 140 the gateway system 30 generates a second hash 208' from the command 204 using the same hash algorithm as used by the client device 10.
  • step 142 correspondence of the command 204 with the first hash 208 is verified by comparing the second hash 208' with the received first hash 208 to ensure that the command 204 has not been modified. This is particularly useful in case the command 204 contains parameters and users are only allowed to use the given command 204 with specific parameters or parameter ranges.
  • step 138 verification of user privileges, step 138, follows. In this embodiment verification of user privileges, step 138, does not only include the check whether the user has the right to issue the command 204, but more specifically whether is has the privilege to issue the command 204 with the specific parameters the command 204 contains. After successful verification the original command 204 is transmitted in step 144 by the gateway system 30 to the HUB 44 of the secured system from where it is routed over the secured or hidden network 46 to the second device 42 addressed by the command 204 to perform the function contained in the command 204.
  • the present invention has the advantage that the original command 204 did not need to be modified and the legacy (secured system 40 and second device 42) does not recognize anything from the very high level of protection which has been integrated into the communication.
  • This is achieved by preparing a derivative, a command identification data 205 of the original command, performing first a local control of the command identification data 205 based on stored user credentials in the secure element 20 of the user, individualizing and digitally signing this command identification data 205.
  • Individualization is achieved by generating a complex data block comprising some or all data elements from a group of a user ID (CIN 210), transaction ID (unique identifier 212), timestamp 214 and potentially other further data elements.
  • the signed data block 218 is sent from the client device 10 together with the original command 204 to the gateway system 30, where integrity, validity, and authenticity of the signed data block 218 is verified and when all checks are successful the original command 204 is verified against the command identification data 205. Should the original command match the command identification data 205, and its values fall between predefined user specific parameters, the original command 204 is forwarded to the secured system 40 the same way as if no additional security checks would have been performed by the user secure element 20 and the gateway system 30.
  • Example 1 Smart home operation.
  • the home has a complex smart operating system which comprises light and temperature control, including the closing and opening of shades and shutters, watering the lawn with a sprinkler system, the manipulation of surveillance cameras, and even the opening and locking of the gate as well as the main entrance and windows.
  • the management of all these devices can be performed through a communication HUB 44 even remotely using a dedicated application on a smart phone (client device 10).
  • the HUB 44 is capable of performing some basic level of user authentication and authenticated users can perform all possible functions without any further controls.
  • a secure system is added to the legacy home management system, comprising the secure gateway system 30, the extension of the user’s mobile management application with some additional functions and chip card management capability, and the introduction of smart cards 20a.
  • First the gateway system 30 is configured which task comprises
  • the associated credentials are stored on the users’ smart cards 20a. This process may be performed locally with the gateway system 30 itself but the credentials may even be distributed remotely over the air, using the mobile phone’s NFC antenna. Remote credential distribution has the advantage that even ad hoc changes in the roles may be performed with simple logistics, without the personal presence of the user.
  • parents may open and close the front door all day long. This means that they select the door opening icon as the command 204 in the mobile program 12a, the program 12a generates the associated command code 206 and requests the smart card 20a to be touched to the NFC antenna of the mobile phone.
  • the command 204 may be issued by the user, the smart card 20a individualizes the command code 206 with a timestamp 214, a unique ID 212, the CIN 210, signs the generated data block 216 and returns this information to the mobile application (program 12a). This whole control function should be performed in a very short time.
  • the mobile application takes the signed command code 206 and the original command 204, establishes secure communication with the gateway system 30 and sends this data packet 220 to the gateway system 30.
  • the gateway system 30 checks the signature of the signed data block 218, generated by the smart card 20a, assuring that the message has not been tampered with, then continues with checking the timestamp 214 for validity and the unique ID 212 to make sure that it has not been used yet. Eventually the user’s credential is checked in the gateway system's 30 database 36. When the message passes all these controls the syntax of the original command 204 is validated to assure that it corresponds to the command code 206 which has been proofed by the smart card 20a. In case all the results are positive the original command 206 is forwarded to the HUB 44 of the home management system, which will forward it to the door, which then will be opened.
  • the control at the gateway system 30 would have included a check of the credential parameters to assure that all rules are properly observed.
  • the door opening command 204 would be forwarded to the gateway HUB 44 only outside the restricted period.
  • Example 2 Connected car
  • a different application use case of the secure gateway system 30 is the protection of connected cars. Having remote communication access to the car is a great new feature adding to convenience and user friendliness, may even save cost through predictive maintenance and lower insurance fees, but it carries also great risks. Unless there is very strong protection the remote connection may turn out to be a real threat for all the passengers of the vehicle. (It has been demonstrated that using the remote communication channel of a car full control including steering and breaking can be taken over from the driver while on the road.)
  • the secure gateway system 30 may just provide the right protection, with blocking access for everyone without the necessary credentials, and allowing only specific tasks to be performed which are delegated to the individual users.
  • the configuration of the gateway system 30 would be performed by the manufacturer who would retain all admin rights. It would create a set of credentials for itself which could include monitoring of all key parts of the car. A different set of credentials - role - would be generated for the insurance company, who could monitor speed, acceleration and similar information related to the driver’s driving habit. The repair stations would also receive a specific set of rights and associated credentials. And obviously the future drivers of the car would have their own credentials too.
  • the new owner receives a secure element 20 in the cloud which is associated with the new vehicle. All the driver associated credentials are available there and when the mobile car management application is used it communicates with this remote secure element 20 to issue the various commands 204 which may include the retrieval of performance parameters, turning on heating or cooling, looking up route history, etc.
  • the workshop will also receive a set of credentials associated with the specific car.
  • the service has its credentials stored on a chip card 20a which is connected to the service’s computer system, and can carry the data of all the cars serviced by the shop in a virtually separated area for each car on the same chip.
  • the service station receives its credentials remotely over the air from the manufacturer. The same scenario is performed in respect of the insurance company of the driver though the insurer will get a different set of credentials.
  • the car’s secure gateway 30 may automatically establish communication with the actors having the right to communicate with it, without waiting for them to start the communication. This capability assures that all information would always be available in respect of the vehicle.
  • the other difference is the strength of message protection which may require that a hash 208 of the original command 204 is also signed by the secure element 20 to assure that not only the command 204 corresponds to the command code 206 but none of its parameters have been modified either.

Abstract

The invention relates to a method for ensuring secure and authorized communications between a first device and a second device, the method comprising: - providing a gateway system suitable for data communication with the first device via a first electronic communication channel and with the second device via a second electronic communication channel, - providing user privileges, at least one user credential relating to at least one command executable by the second device; - providing a key pair of Public key cryptography having a private key and a public key, - receiving by the gateway system from the first device via the first electronic communication channel at least one data packet comprising a command executable by the second device and a data block containing at least command identification data of the command, the data block being signed by the private key; - verifying the at least one data packet by the gateway system by: - verifying integrity of the signed command identification data using the public key; - verifying correspondence of the command with the command identification data; - in case of successful verification of the at least one data packet transmitting by the gateway system the command to the second device via the second electronic communication channel. The invention further relates to a gateway system and a computer program product for performing the method according to the invention.

Description

Method for ensuring secure and authorized communications between a first device and a second device
The present invention relates to a method for ensuring secure and authorized communications between a first device and a second device.
Today with the ubiquity of the internet we have access remotely to a range of systems, in our offices and homes. Unless these are highly sophisticated solutions with professional management the level of associated security is quite low, sometimes even nonexistent. This is a serious situation which has been industry wide identified, but not successfully addressed yet. The problems, the vulnerability and the potential losses and threats will exponentially grow with the proliferation of loT (Internet of Things) which introduces the internet and remote communication to all aspects of our life. In the future security systems will not only have to protect financial resources, data and information but frequently human life as well.
Although the risks have been identified, the adequate solutions are either missing, are too expensive or deteriorate the core functionality, usability, therefore many systems are presently sold and implemented without adequate protection. Such practices already today may lead to large scale attacks (Like the Mirai botnet orchestrating a large scale DDoS attack building on the lack of protection in thousands of IP cameras and taking down much of America’s internet infrastructure.) which only provided some light demonstration what may happen to us in the future if we do not treat the security challenge more seriously.
Even some novel services like smart homes or remote health monitoring, use some type of user name and password or biometric based protection, but it has been demonstrated upon several occasions that such security measures can be hacked. The applied solutions may have been satisfactory when a room could be monitored by a camera remotely, but when the same camera can also be turned off and the door opened using a mobile app. the level of necessary security measures need to be dramatically increased.
Thus there is a need for increasing the security level of remote operations.
The present invention has for objective to overcome the problems associated with the prior art solutions. In particular, the present invention has for objective to protect a remotely operable second device (which may even be a complex system as well) without the need to change anything on the device itself, with only slight modification of the application running on a remote first (client, user) device, which operates the second (secured, protected) device.
The inventor of the present invention proposes an economically sound approach to install an additional device, a secure gateway into the present communication channel between the first and second devices and provide the highest level of user and credential authentication and authorization. With the proposed solution even existing implementations can be upgraded to the highest security level with marginal expenses, without the need to modify the protected system. This way all that is needed is to integrate a secure element and some additional functions into the front-end management application, running on the first device.
This objective is achieved by Method for ensuring secure and authorized communications between a first device and a second device, the method comprising: - providing a gateway system suitable for data communication with the first device via a first electronic communication channel and with the second device via a second electronic communication channel,
- providing user privileges, at least one user credential relating to at least one command executable by the second device;
- providing a key pair of Public key cryptography having a private key and a public key,
- receiving by the gateway system from the first device via the first electronic communication channel at least one data packet comprising at least one command executable by the second device and a data block containing at least command identification data of the at least one command, the data block being signed by the private key;
- verifying the at least one data packet by the gateway system by:
- verifying integrity of the signed command identification data using the public key;
- verifying correspondence of the command with the command identification data;
- in case of successful verification of the at least one data packet transmitting by the gateway system the command to the second device via the second electronic communication channel.
In the context of the present invention the term "at least one data packet comprising at least one command executable by the second device, and a data block containing at least command identification data of the at least one command, the data block being signed by the private key" is understood to have the meaning that the at least one command and the command identification data of the at least one command can be contained in a single data packet or can be contained in more than one data packets. In case more data packets are received by the gateway, the data packets are preferably linked to each other.
Preferably the method further comprises:
- providing the first device with a first secure element;
- storing the private key in the first secure element; and - signing the data block by the first secure element using the private key.
Preferably, the first secure element is an embedded secure element in the first device, or a removable card (e.g. SIM card, SD card) of the first device, or an external smart card connectable to the first device, or a software application
(e.g. Trusted Execution Environment) of the first device, or a secure storage facility in a cloud on a remote server, or similar.
The command identification data preferably comprises a command code associated with the command by the first device.
Alternatively, or in addition, the command identification data preferably comprises a hash of the command, which hash is generated by the first device using a hash algorithm.
According to a preferred embodiment the user identification data is an identifier of the first secure element, such as Card Identification Number (CIN) of a smart card or a SIM card.
According to another preferred embodiment the user identification data is based on the signature applied to the data block, for example the public key certificate corresponding to the private key.
Further advantageous embodiments are defined in the appended dependent claims.
Further details of the invention will be apparent from the accompanying figures and exemplary embodiments.
Fig. 1 is a schematic block diagram of an exemplary embodiment of a system suitable for carrying out the method according to the invention.
Fig. 2 is a more detailed block diagram of certain element of Fig. 1.
Fig. 3a and 3b are flow diagrams illustrating the steps of an exemplary embodiment of the present invention.
Fig. 4a and 4b are flow diagrams illustrating the steps of another exemplary embodiment of the present invention.
Fig. 5a and 5b are flow diagrams illustrating the steps of another exemplary embodiment of the present invention. The exemplary embodiment illustrated in Fig. 1 and Fig. 2 comprises a first client device 10 equipped with a secure element 20, a gateway system 30, a secured system 40 including at least one remotely controllable second device 42 and a Public key cryptography key pair 50 consisting of a private key 50a and a public key 50b. The public key infrastructure may be based on any kind of cryptographic algorithms, including post-quantum cryptographic algorithms as well. The client device 10 and the gateway system 30 are connectable via an electronic communication channel 60, which is preferably established over the Internet 62.
According to the present embodiment the client device 10 is a personal computer having a processor 11 , a data storage 12, a communication unit 13, a secure element interface 14, a display 15 and a user input interface 16 e.g. keyboard, touchscreen, mouse, etc. Other client devices could be used as well, such as a smart phone, tablet, laptop, smart watch, etc. These devices have similar structure, accordingly the present description applies mutatis mutandis.
Preferably, a program 12a for generating and sending operation commands to the remotely controllable second device 42 is stored in the data storage 12 of the computer 10.
According to the present embodiment the secure element 20 is a smart card 20a, which also comprises a processor 21 , a secure storage 22 (usually built together in one microcontroller) and a communication interface 23 for communicating with the client device 10 over the smart card interface 14. In the present case the private key 50a is stored in the secure storage 22. Preferably, user authentication data 24 and user privileges data 25 are also stored in the secure storage 22. Other types of secure elements 20 are also conceivable as will be apparent for a skilled person, for example an embedded secure element in the client device 10, a removable card (e.g. SIM card, SD card) of the client device 10, an external smart card connectable to the client device 10, a software application (e.g. Trusted Execution Environment) of the client device 10, or a secure storage facility in a cloud on a remote server.
According to the present embodiment the gateway system 30 comprises a gateway computer 32, which is a small computer having at least a processor 33, a data storage 34 and a communication unit 35. The communication unit 13 of the client device 10 and the communication unit 35 of the gateway system 30 are connectable via the electronic communication channel 60. Preferably the computer 32 is suitable for establishing the electronic communication channel 60 with the client device 10 over the Internet 62 in the form of a VPN connection (Virtual Private Network connection). Preferably a user database 36 is provided and stored in the data storage 34 of the gateway computer 32. Alternatively, the user database 36 may be stored at a remote location, which is accessible by the gateway system 30, in particular by the gateway computer 32.
The gateway system is preferably equipped with a secure element 70, which is preferably a smart card 70a connected to a smart card interface 37 of the gateway computer 32. In the present case the secure element 70 comprises a processor 71 , a secure storage 72 and a communication interface 73 for communicating with the gateway computer 32 via the smart card interface 37. The secure element 70 of the gateway system 30 may have various form factors or types, including, but not limited to SIM card, SD card, embedded secure element, trusted execution environment, external plastic card as well as remotely connected secure storage facility.
The public key 50b of the Public key cryptography key pair 50 is preferably stored in the secure storage 72 of the secure element 70 as illustrated in Fig. 2, however, it may also be stored in the data storage 34 of the gateway computer 32 or at a remote location, which is accessible by the gateway system 30. Public keys are stored in the secure storage if it needs to be assured that only keys belonging to the system may be used. For this reason keys related to admin privileges and keys related to secure storage management privileges preferably are stored here. It should also be noted that for specific configurations (eg. when X.509 public key certificates are used) the public key 50b should not necessarily be stored at all in the gateway system 30 for the system to operate properly as it could also be received from the remote client device 10, during the communication. ln certain cases the user database 36 may also be stored in the secure storage 72 of the secure element 70 instead of the data storage 34 of the gateway computer 32.
The gateway system 30 preferably further comprises a firewall 38, which can be configured according to the privileges of the users of the system, and or according to the specifics of the secured system 40. Furthermore it may be configured to block any communication not corresponding to specific parameters.
According to the present embodiment the protected system 40 comprises a HUB 44 and a secured or hidden network 46 connecting two or more remotely controllable devices 42 with the HUB 44. The HUB is also connected to the gateway system 30 such that all external communication has to pass through the gateway system 30.
The method according to the present invention is performed with the system schematically depicted in Figs. 1 and 2 as follows.
The user is assigned the smart card 20a, which is registered in the user database 36 of the gateway system 30. The Public key cryptography key pair 50 is preferably generated in the smart card 20a and the private key 50a is stored in the secure storage 22 of the smart card 20a, while the public key 50b may be transmitted to the gateway system 30, where it can be stored in the secure storage 72 of the second smart card 70a.
User privileges (privileges) are also assigned to the user and registered in the user database 36 in the data storage 34 of the gateway system 30. Preferably some or all user privileges data 25 are transmitted to the smart card 20a as well, and stored in the secure storage 22 thereof.
After the system has been set up an exemplary method according to the invention is carried out as illustrated in Figs. 3a and 3b. It will be appreciated that the order of the steps may differ from the order presented here.
According to the present example, in step 100 the user authenticates himself by inputting via the input interface 16 of the client device 10 user authentication data. The user is authenticated by the smart card 20a connected with the client device 10. Preferably, the smart card has a unique PIN 200 which the user needs to know and needs to input upon request to be able to perform any transaction with it. Other type of user authentication data may be used as well, such as biometric identifiers. If the client device 10 is such a device which is typically used by a single user (e.g. a mobile phone), additionally a client device identifier 202 of the client device 10 (e.g. telephone number or serial number of the mobile phone, IMEI, or MAC address) may also be used, or a special ID of the program 12a running on the client device 10 (e.g. registration ID) thereby linking the user to the client device 10 and/ or to a specific application as well, which increases the level of security.
In step 102 a command 204 is generated for the remotely controllable second device 42 with the program 12a stored in the data storage 12 of the client device 10. In step 104 the program 12a generates command identification data 205 from the command 204. In the present example the command identification data 205 is a command code 206.
The command code 206 is a short code derived from the command 204 and serving to identify the command 204. For example in case the second device 42 is remotely controllable lamp, the command for switching the light on may have a command code 206 such as "LON" and the command for switching the light off may have a command code 206 such as "LOFF".
In step 106 the user authentication data (unique PIN 200 and client device identifier 202) and the command identification data 205 are transmitted to the smart card 20a that is connected to the user device 10 via the smart card interface 14 of the client device 10. The user authentication data and the command identification data 205 may be transmitted in separate steps as well.
In step 108 the smart card 20a compares the received user authentication data with the user authentication data 24 stored in the secure storage 22 of the smart card 20a in order authenticate the user. If the user is successfully authenticated, the process continues, otherwise an error response or the like may be sent back to the client device 10.
In step 110 the smart card 20a verifies the command code 206 by checking the user privileges data 25 stored in the secure storage 22 in order to determine whether or not the authenticated user has the necessary privileges to use the command 204 which is defined by the command code 206. If the authenticated user is allowed to transmit the command 204, which is defined by the command code 206, to the secured system 40 then the verification step is successful and the process continues, otherwise an error response or the like may be sent back to the client device 10.
In step 112 the smart card 20a retrieves its CIN (card identification number) 210, in step 114 the smart card 20a generates a unique identifier 212 for the specific transaction, and in step 116 the smart card 20a generates a timestamp 214 too. In step 118 the command identification data 205, (which is now the command code 206), the CIN 210, the unique identifier 212 and the timestamp 214 are all concatenated in order to create a data block 216, which is then signed in step 120 by the smart card 20a using the private key 50a stored in its secure storage 22, whereby a signed data block 218 is obtained. The steps of generating the additional data and the step of concatenating the various data may follow any order or be carried out in more steps sequentially, as is clear for a person skilled in the art. Also not all the steps of 112, 114, 116 need to be carried out for all implementations. In step 122 the signed data block 218 is transmitted back to the client device 10 via the communication interface 23 of the smart card 20a.
In step 124 the client device generates a client data packet 220 containing the original command 204 and the signed data block 218.
In step 126 the communication unit 13 of the client device 10 transmits the client data packet 220 to the gateway system 30 through the electronic communication channel 60 established over the Internet 62, which is preferably a VPN connection. It is also possible to send the original command 204 and the signed data block 218 in separate data packets, which are linked to each other e.g. by message identifiers.
The steps 104, 106, 124 and 126 may be performed by the program 12a itself, generating and sending operation commands 204 to the remotely controllable second device 42, stored in the data storage 12 of the client device 10, or may even be carried out by a second application dedicated for these functions and also forming a bridge between the program 12a and the secure element 20.
In step 128 the client data packet is received by the gateway system 30 and the command 204 is separated from the signed data block 218. In case of two data packets separation is not required instead the gateway system 30 checks whether or not the two data packets are linked to each other.
In step 130 the gateway system 30 obtains user identification data from the user database 36 based on the signed data block 218 for identifying the public key 50b of the Public key cryptography key pair 50 of which the private key 50a has been used for signing the data block 216. In the present example the user identification data is the CIN 210 contained in the signed data block 218, since the smart card 20a is assigned to the user. The signature created by the unique private key 50a and applied to the data block 216 may also serve as the user identification data, when used with a PKI certificate.
A public key certificate may be sent by the smart card 20a together with the signed data block 218. In this case the public key 50b may also be stored in the client device 10, or the secure storage 22 of the smart card 20a thereof and not by the gateway system 30.
In step 132 the gateway system verifies the integrity of the signed data block 218 by checking the signature of the signed data block 218 using the public key 50b. If the check fails it means that the data block has either been manipulated, or the client is not the one who it claims to be.
If the signed data block 218 is valid and intact, uniqueness and expiration of the data block is verified in steps 134 and 136. In step 134 uniqueness of the command 204 is verified based on the unique identifier 212 contained in the signed data block 218: the gateway system 30 checks whether or not the unique identifier 212 has already been previously used, if yes the command 204 will not be forwarded to the second device 42 of the secured system 40. In step 136 expiration is verified based on the timestamp 214, current time and a pre-set expiry value, e.g. 10 minutes. The gateway system 30 checks whether or not the pre-set expiry value had already expired since the timestamp 214 was applied, if yes the command 204 will not be forwarded to the second device 42.
In step 138 the user privileges of the user identified by the CIN 210 (or by the digital signature itself) are obtained from the user database 36 and verified in order to check the user's right to use the original command 204 based on the command code 206.
In step 142 the gateway system checks whether the original command 204 received as part of the client data packet 220 corresponds to the command code 206 received. Verification may be done by performing a syntactic check of the command 204, or some kind of transformation of the original command 204 which should result in the command code 206 unless the original command 204 has been tampered.
According to the present example, in step 140 the gateway system 30 regenerates a control command code 206' using the same code generation algorithm as used by the client device 10. In step 142 this control command code 206' is compared with the received first command code 206 to ensure that the command 204 has not been modified. Comparison is of course not required if the original command 204 has been modified in such a way that it is no longer possible to derive a control command code 206' therefrom. In such cases the request to transmit the command 204 can be declined without further verification.
When all the verifications are successfully performed the original command 204 is transmitted in step 144 by the gateway system 30 to the HUB 44 of the secured system 40 from where in step 146 it is routed over the secured or hidden network 46 to the second device 42 addressed by the command 204 to perform the function contained in the command 204.
Figs. 4a and 4b illustrate the steps of a second preferred embodiment. The same reference numerals have been used for corresponding steps and entities. It will be appreciated that the order of the steps may differ from the order presented here. It has been realized that it is also possible to delegate much of the whole client credential control to the secure element 20 (smart card 20a) connected to the client device 10. In the embodiment illustrated in Figs. 4a and 4b the program 12a running on the client device 10 generates in step 104 a first hash 208 of the command 204 and uses this information as the command identification data 205.
The first hash (digest) 208 of the command 204 is generated by the program 12a using a hash algorithm (e.g. SHA-256). The first hash 208 is a compressed data obtained from the original command 204 which does not allow reconstruction of the original command 204. If the original command 204 is modified and the hash algorithm is applied to the modified command 204 this will result in a substantially different hash, whereby the first hash 208 can be used for tamper proofing as known in the art.
In step 106 the user authentication data (unique PIN 200 and client device identifier 202) and the command identification data 205 (which is now the command hash 208) are transmitted to the smart card 20a that is connected to the user device 10 via the smart card interface 14 of the client device 10. The user authentication data and the command identification data 205 may be transmitted in separate steps as well.
Following user authentication as described in the first embodiment the smart card 20a verifies in step 110 the first hash 208 of the command 204 by checking the user privileges data 25 stored in the secure storage 22 in order to determine whether or not the authenticated user has necessary privileges to use the command 204 which is defined by the command hash 208. If the authenticated user is allowed to transmit the command 204, which is defined by the command hash 208, to the secured system 40 then the verification step is successful and the process continues, otherwise an error response or the like may be sent back to the client device 10.
In this embodiment all further steps performed by the smart card 20a and the mobile program 12a running on the client device 10 are the same as described above. Even the gateway system performs the same control steps up to step 136. According to the present embodiment step 138, i.e. verification of the user privileges may be omitted as the system fully trusts the verification performed by the secure element 20, connected to the client device 10.
In order to check that the same command 204 has been sent in the client data packet 220 as what has been verified in step 110 by the smart card 20a, the gateway generates a second hash 208' from the original command 204 in step 140 and compares it in step 142 with the first hash 208 received in the client data packet 220 to assure that the command 204 has not been manipulated and the user has the necessary privileges. After successful verification the original command 204 is transmitted in step 144 by the gateway system 30 to the HUB 44 of the secured system from where it is routed over the secured or hidden network 46 to the second device 42 addressed by the command 204 to perform the function contained in the command 204.
A further preferred embodiment illustrated in Figs. 5a and 5b combines the above described two embodiments by generating in step 104 both the command code 206 and the first hash 208 of the command 204 by the program 12a running on the client device 10 and using them together as the command identification data 205.
According to the present embodiment, the user authentication data consists of the unique PIN 200 only, which is transmitted together with the command identification data 205 (consisting of the command code 206 and the command hash 208) in step 106 to the smart card 20a that is connected to the user device 10 via the smart card interface 14 of the client device 10. The smart card 20a performs all the steps as described in the first embodiments but also includes the first hash 208 of the command 204 in the data block 216 which is then signed. From this point on all the steps performed by the smart card 20a, the program 12a on the client device 10 and the gateway system 30 are identical with what has been described in connection with the first embodiment until checking user privileges in step 138. In this embodiment checking of user privileges in step 138 is performed after tamper proofing the original code in step 142, because a more detailed control will be carried out. In step 140 the gateway system 30 generates a second hash 208' from the command 204 using the same hash algorithm as used by the client device 10. In step 142 correspondence of the command 204 with the first hash 208 is verified by comparing the second hash 208' with the received first hash 208 to ensure that the command 204 has not been modified. This is particularly useful in case the command 204 contains parameters and users are only allowed to use the given command 204 with specific parameters or parameter ranges. In such cases a simple command code 206 may not suffice to adequately code the command 204 with every possible parameter or parameter combination, whereby the command code 206 only serves to identify the command 204 but not the applied parameters. Comparison of the first hash 208 and the second hash 208' allows for validating whether or not these parameters have been modified. In case of successful match of the two hashes 208, 208' verification of user privileges, step 138, follows. In this embodiment verification of user privileges, step 138, does not only include the check whether the user has the right to issue the command 204, but more specifically whether is has the privilege to issue the command 204 with the specific parameters the command 204 contains. After successful verification the original command 204 is transmitted in step 144 by the gateway system 30 to the HUB 44 of the secured system from where it is routed over the secured or hidden network 46 to the second device 42 addressed by the command 204 to perform the function contained in the command 204.
As can be seen the present invention has the advantage that the original command 204 did not need to be modified and the legacy (secured system 40 and second device 42) does not recognize anything from the very high level of protection which has been integrated into the communication. This is achieved by preparing a derivative, a command identification data 205 of the original command, performing first a local control of the command identification data 205 based on stored user credentials in the secure element 20 of the user, individualizing and digitally signing this command identification data 205. Individualization is achieved by generating a complex data block comprising some or all data elements from a group of a user ID (CIN 210), transaction ID (unique identifier 212), timestamp 214 and potentially other further data elements. The signed data block 218 is sent from the client device 10 together with the original command 204 to the gateway system 30, where integrity, validity, and authenticity of the signed data block 218 is verified and when all checks are successful the original command 204 is verified against the command identification data 205. Should the original command match the command identification data 205, and its values fall between predefined user specific parameters, the original command 204 is forwarded to the secured system 40 the same way as if no additional security checks would have been performed by the user secure element 20 and the gateway system 30.
In the following two concrete examples are shown to illustrate the application of the present invention:
Example 1 : Smart home operation.
The home has a complex smart operating system which comprises light and temperature control, including the closing and opening of shades and shutters, watering the lawn with a sprinkler system, the manipulation of surveillance cameras, and even the opening and locking of the gate as well as the main entrance and windows. The management of all these devices can be performed through a communication HUB 44 even remotely using a dedicated application on a smart phone (client device 10).
The HUB 44 is capable of performing some basic level of user authentication and authenticated users can perform all possible functions without any further controls.
To make the operation more secure and sophisticated a secure system is added to the legacy home management system, comprising the secure gateway system 30, the extension of the user’s mobile management application with some additional functions and chip card management capability, and the introduction of smart cards 20a.
First the gateway system 30 is configured which task comprises
• delegation of an Admin function to the key user • the recording of all the possible functions in a database including possible parameters which may provide limits of certain operations (like max. temperature setting)
• the registration of users together with their assigned card IDs
• delegation of functions to individual users, with parameter limits if relevant (like entry - opening the door - is only allowed between 9am and 5pm for the house keeper)
When the users are registered they are each assigned their individual, personalized smart cards 20a carrying the card ID (CIN 210), the service application of the system, their own private keys 50a, certificates and potentially even some other information.
When the individual roles have been defined, the associated credentials are stored on the users’ smart cards 20a. This process may be performed locally with the gateway system 30 itself but the credentials may even be distributed remotely over the air, using the mobile phone’s NFC antenna. Remote credential distribution has the advantage that even ad hoc changes in the roles may be performed with simple logistics, without the personal presence of the user.
After setting up the secure system, users have specific, individually tailored rights, roles with the home management system. They all use the same mobile application (program 12a), but still will not be able to perform the same functions.
According to the present settings parents may open and close the front door all day long. This means that they select the door opening icon as the command 204 in the mobile program 12a, the program 12a generates the associated command code 206 and requests the smart card 20a to be touched to the NFC antenna of the mobile phone. When the user touches the smart card 20a to the NFC antenna of the mobile phone (client device 10) it will request the PIN 200 of the user. If the PIN 200 is provided correctly the smart card 20 will check based on the stored list of credentials whether this specific user has the necessary right to issue the command 204 represented with the command code 206. If the command code 206 is included in the list, the command 204 may be issued by the user, the smart card 20a individualizes the command code 206 with a timestamp 214, a unique ID 212, the CIN 210, signs the generated data block 216 and returns this information to the mobile application (program 12a). This whole control function should be performed in a very short time. The mobile application takes the signed command code 206 and the original command 204, establishes secure communication with the gateway system 30 and sends this data packet 220 to the gateway system 30. The gateway system 30 checks the signature of the signed data block 218, generated by the smart card 20a, assuring that the message has not been tampered with, then continues with checking the timestamp 214 for validity and the unique ID 212 to make sure that it has not been used yet. Eventually the user’s credential is checked in the gateway system's 30 database 36. When the message passes all these controls the syntax of the original command 204 is validated to assure that it corresponds to the command code 206 which has been proofed by the smart card 20a. In case all the results are positive the original command 206 is forwarded to the HUB 44 of the home management system, which will forward it to the door, which then will be opened.
Should the children have issued the same door opening command, who are not allowed to open the door after 8pm till 7am, the control at the gateway system 30 would have included a check of the credential parameters to assure that all rules are properly observed. The door opening command 204 would be forwarded to the gateway HUB 44 only outside the restricted period.
On the other hand the gardener could not have issued the same command 204. Already the smart card 20a would have rejected it, if the gardener only has rights to open the gate, but not the front door.
By installing the secure gateway system 30 between the HUB 44 and the legacy mobile application (program 12a) the whole home management system became much more secure, sophisticated, and no changes needed to be carried out on either the HUB 44 or any of the smart modules of the home.
Example 2: Connected car A different application use case of the secure gateway system 30 is the protection of connected cars. Having remote communication access to the car is a great new feature adding to convenience and user friendliness, may even save cost through predictive maintenance and lower insurance fees, but it carries also great risks. Unless there is very strong protection the remote connection may turn out to be a real threat for all the passengers of the vehicle. (It has been demonstrated that using the remote communication channel of a car full control including steering and breaking can be taken over from the driver while on the road.)
The secure gateway system 30 may just provide the right protection, with blocking access for everyone without the necessary credentials, and allowing only specific tasks to be performed which are delegated to the individual users.
In this scenario the configuration of the gateway system 30 would be performed by the manufacturer who would retain all admin rights. It would create a set of credentials for itself which could include monitoring of all key parts of the car. A different set of credentials - role - would be generated for the insurance company, who could monitor speed, acceleration and similar information related to the driver’s driving habit. The repair stations would also receive a specific set of rights and associated credentials. And obviously the future drivers of the car would have their own credentials too.
When the cars are shipped none of the credentials are issued yet to the users, only the manufacturer would have its own rights. Upon selling a car the new owner receives a secure element 20 in the cloud which is associated with the new vehicle. All the driver associated credentials are available there and when the mobile car management application is used it communicates with this remote secure element 20 to issue the various commands 204 which may include the retrieval of performance parameters, turning on heating or cooling, looking up route history, etc. When the driver selects a repair station, the workshop will also receive a set of credentials associated with the specific car. The service has its credentials stored on a chip card 20a which is connected to the service’s computer system, and can carry the data of all the cars serviced by the shop in a virtually separated area for each car on the same chip. The service station receives its credentials remotely over the air from the manufacturer. The same scenario is performed in respect of the insurance company of the driver though the insurer will get a different set of credentials.
From this point on the generation of commands 204 by the mobile application of the driver, or the PC based applications of the other actors, as well as the controls performed by the gateway system 30 are the same as they are described above in the first example.
There may however be a couple of slight differences. One may be that the car’s secure gateway 30 may automatically establish communication with the actors having the right to communicate with it, without waiting for them to start the communication. This capability assures that all information would always be available in respect of the vehicle. The other difference is the strength of message protection which may require that a hash 208 of the original command 204 is also signed by the secure element 20 to assure that not only the command 204 corresponds to the command code 206 but none of its parameters have been modified either.
Various modifications to the above disclosed embodiments will be apparent to a person skilled in the art without departing from the scope of protection determined by the attached claims.

Claims

1. Method for ensuring secure and authorized communications between a first device and a second device, the method comprising:
- providing a gateway system suitable for data communication with the first device via a first electronic communication channel and with the second device via a second electronic communication channel,
- providing user privileges, at least one user credential relating to at least one command executable by the second device;
- providing a key pair of Public key cryptography having a private key and a public key,
- receiving by the gateway system from the first device via the first electronic communication channel at least one data packet comprising a command executable by the second device and a data block containing at least command identification data of the command, the data block being signed by the private key;
- verifying the at least one data packet by the gateway system by:
- verifying integrity of the signed command identification data using the public key;
- verifying correspondence of the command with the command identification data;
- in case of successful verification of the at least one data packet transmitting by the gateway system the command to the second device via the second electronic communication channel.
2. The method according to claim 1 , wherein the data block further contains a unique identification data and the step of verifying the at least one data packet further comprises verifying uniqueness of the at least one data packet based on the unique identifier.
3. The method according to claim 2, wherein the step of verifying uniqueness of the at least one data packet comprises verifying whether or not it is the first time that the unique identifier is used.
4. The method according to claim 1 , wherein the data block further contains a timestamp and the step of verifying the at least one data packet further comprises verifying expiry of the at least one data packet based on the timestamp, current time and a pre-set expiry value.
5. The method according to claim 1 , wherein the data block further contains a user identification data and the step of verifying the at least one data packet further comprises verifying user privileges relating to the command based on the received user identification data.
6. The method according to claim 1 , wherein the step of verifying the at least one data packet further comprises determining the user based on a signature applied to the data block and verifying user privileges of the determined user relating to the command.
7. The method according to claims 5 or 6, wherein verifying user privileges relating to the command includes verifying parameters of the command.
8. The method according to claim 1 , wherein the command identification data is a command code associated with the command and verifying correspondence of the command with the command identification data comprises matching the command code and the received command.
9. The method according to claim 8, wherein verifying correspondence of the command with the command identification data includes syntactic verification of the command.
10. The method according to claim 1 , wherein the command identification data comprises a first hash of the command and verifying correspondence of the command with the command identification data comprises generating a second hash of the command and comparing the second hash and the first hash.
11. The method according to claim 1 , wherein the step of verifying the at least one data packet comprises determining by the gateway system the second device to which the command is destined from among a plurality of devices.
12. The method according to claim 1 , comprising receiving by the gateway system from the first device via the first electronic communication channel at least two data packets, wherein the command executable by the second device is contained in one data packet and the signed data block is contained in another data packet, and the at least two data packets are related to each other.
13. The method according to claim 1 , wherein the first device comprises a data storage storing a program for generating the command, the method further comprising:
- providing the first device with a first secure element;
- storing the private key in the first secure element;
- generating the command by the program stored in the data storage of the first device;
- generating the command identification data of the command by the first device; and
- electronically transmitting the command identification data by the first device to the first secure element,
- generating the data block comprising the command identification data by the first secure element,
- signing the data block by the first secure element with the private key, - electronically transmitting the signed data block by the first secure element to the first device,
- generating the at least one data packet by the first device, and
- electronically transmitting the at least one data packet by the first device to the gateway system.
14. The method according to claim 1 , comprising:
- providing the first device with a first secure element;
- storing the private key in the first secure element;
- generating the command by the first secure element;
- generating the command identification data of the command by the first secure element; and
- generating the data block comprising the command identification data by the first secure element,
- signing the data block by the first secure element with the private key,
- generating the at least one data packet by the first device, and
- electronically transmitting the at least one data packet by the first device to the gateway system.
15. The method according to claim 13, comprising
- providing a unique identifier by the first secure element,
- generating the data block comprising the command identification data and the unique identifier by the first secure element,
- and the step of verifying the at least one data packet further comprises verifying uniqueness of the command based on the received unique identifier data.
16. The method according to claim 13, comprising storing user identification data in the first secure element, including the user identification data in the generated data block, and the step of verifying the at least one data packet further comprises verifying user privileges relating to the command based on the received user identification data.
17. The method according to claim 16, comprising associating a user with the first secure element having a secure element identifier, and including by the secure element the secure element identifier as the user identification data in the generated data block.
18. The method according to claim 13, comprising generating the command identification data of the command includes generating a first hash of the command, including the first hash of the command in the generated data block and verifying the command based on the command identification data comprises generating a second hash of the command and comparing the second hash and the first hash.
19. The method according to claim 18, storing user privileges relating to command hashes in the first secure element; verifying by the first secure element the user privileges related to the received command hash; and generating and signing the data block by the first secure element in case the received command hash matches the user privileges.
20. The method according to claim 13, comprising generating the command identification data of the command includes associating a command code with the command, including the command code in the generated data block and verifying the command based on the command identification data comprises comparing the command code and the received command.
21. The method according to claim 20, storing user privileges relating to command codes in the first secure element; verifying by the first secure element the user privileges related to the received command code; and generating and signing the data block by the first secure element in case the received command code matches the user privileges.
22. The method according to claim 13, wherein the first secure element is chosen from a group consisting of embedded secure element in the first device, a removable card (e.g. SIM card, SD card) of the first device, an external smart card connectable to the first device, a software application (e.g. Trusted Execution Environment) of the first device, or a secure storage facility in a cloud on a remote server.
23. The method according to claim 13, assigning a personal identifier to a user; authenticating the user by the first device by prompting the user to enter the personal identifier via an input interface of the user communication device and sending the inputted personal identifier to the first secure element for authentication; and generating and signing the data block by the first secure element in case of successful authentication.
24. The method according to claim 13, wherein the stored private key in the first secure element is dedicated to the individual user.
25. The method according to claim 13, wherein the stored private key in the first secure element is the private key of the gateway, used by all the users.
26. A gateway system comprising a processing unit, a data storage and a communication unit, the processing unit being configured to execute the method according to claim 1.
27. A computer program product comprising at least one computer- readable storage medium having computer executable program code instructions stored therein, the computer executable program code instructions comprising program code instructions for performing the method according to claim 1.
PCT/HU2018/050048 2017-11-22 2018-11-20 Method for ensuring secure and authorized communications between a first device and a second device WO2019102239A1 (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
US15/931,313 US11245523B2 (en) 2017-11-22 2020-05-13 Method for implementing client side credential control to authorize access to a protected device

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
HUP1700484 2017-11-22
HUP1700484 2017-11-22

Related Parent Applications (1)

Application Number Title Priority Date Filing Date
PCT/HU2019/050023 Continuation WO2020229853A1 (en) 2017-11-22 2019-05-14 Method for implementing client side credential control to authorize access to a protected device

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US15/931,313 Continuation-In-Part US11245523B2 (en) 2017-11-22 2020-05-13 Method for implementing client side credential control to authorize access to a protected device

Publications (1)

Publication Number Publication Date
WO2019102239A1 true WO2019102239A1 (en) 2019-05-31

Family

ID=89720136

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/HU2018/050048 WO2019102239A1 (en) 2017-11-22 2018-11-20 Method for ensuring secure and authorized communications between a first device and a second device

Country Status (1)

Country Link
WO (1) WO2019102239A1 (en)

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20160173495A1 (en) * 2014-12-16 2016-06-16 Wins Co, Ltd System and method for providing authentication service for internet of things security
US20170141926A1 (en) * 2015-11-13 2017-05-18 Minghua Xu Methods and systems for pki-based authentication

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20160173495A1 (en) * 2014-12-16 2016-06-16 Wins Co, Ltd System and method for providing authentication service for internet of things security
US20170141926A1 (en) * 2015-11-13 2017-05-18 Minghua Xu Methods and systems for pki-based authentication

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
HUICHEN LIN ET AL: "IoT Privacy and Security Challenges for Smart Home Environments", INFORMATION, vol. 7, no. 3, 13 July 2016 (2016-07-13), XP055485161, ISSN: 2078-2489, DOI: 10.3390/info7030044 *

Similar Documents

Publication Publication Date Title
US11245523B2 (en) Method for implementing client side credential control to authorize access to a protected device
US11855839B2 (en) System and method for pre-enrollment and network pre-configuration of internet of things (IoT) devices
CN106257861B (en) By control equipment come the authentication method and its system with auto communication
KR102107391B1 (en) Method and device for control of a lock mechanism using a mobile terminal
CN108667780B (en) Identity authentication method, system, server and terminal
US8301887B2 (en) Method and system for automated authentication of a device to a management node of a computer network
CN106797318B (en) Method, hardware and digital certificate for authentication of connected devices
WO2018157247A1 (en) System and method for securing communications with remote security devices
EP3677005B1 (en) Authentication protocol based on trusted execution environment
US11373762B2 (en) Information communication device, authentication program for information communication device, and authentication method
US10361867B2 (en) Verification of authenticity of a maintenance means connected to a controller of a passenger transportation/access device of a building and provision and obtainment of a license key for use therein
CN105024998A (en) Wireless device monitoring systems and monitoring devices, and associated methods
CN111177695A (en) Intelligent household equipment access control method based on block chain
EP2520061A1 (en) Methods to enable secure self-provisioning of subscriber units in a communication system
CN108701384B (en) Method for monitoring access to electronically controllable devices
US11165569B2 (en) Method and device for securely operating a field device
CN110474921A (en) A kind of perception layer data fidelity method towards local Internet of Things
CN105141639A (en) Cloud-computing-platform-based bluetooth dynamic password security certificate method
KR20220072657A (en) SECURITY CONSTRUCTION METHOD FOR IoT DEVICES PLATFORM AND SECURITY CONSTRUCTION SYSTEM FOR IoT DEVICES PLATFORM BASED ON DUAL BLOCKCHAIN COUPLED WITH VIRTUAL BLOCKCHAIN
WO2019102239A1 (en) Method for ensuring secure and authorized communications between a first device and a second device
WO2020229853A1 (en) Method for implementing client side credential control to authorize access to a protected device
KR20150083178A (en) Method for Managing Certificate
KR102361081B1 (en) Method and system for managing kiosk based on programmable logic controller
EP2529329B1 (en) Secure procedure for accessing a network and network thus protected
CN108886529B (en) System for remotely controlling a vehicle

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 18836495

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 18836495

Country of ref document: EP

Kind code of ref document: A1