GB2570292A - Data protection - Google Patents

Data protection Download PDF

Info

Publication number
GB2570292A
GB2570292A GB1800469.7A GB201800469A GB2570292A GB 2570292 A GB2570292 A GB 2570292A GB 201800469 A GB201800469 A GB 201800469A GB 2570292 A GB2570292 A GB 2570292A
Authority
GB
United Kingdom
Prior art keywords
key
readings
data
public
encrypted
Prior art date
Legal status (The legal status 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 status listed.)
Withdrawn
Application number
GB1800469.7A
Other versions
GB201800469D0 (en
Inventor
Michael Faulks
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Ioetec Ltd
Original Assignee
Ioetec Ltd
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 Ioetec Ltd filed Critical Ioetec Ltd
Priority to GB1800469.7A priority Critical patent/GB2570292A/en
Publication of GB201800469D0 publication Critical patent/GB201800469D0/en
Publication of GB2570292A publication Critical patent/GB2570292A/en
Withdrawn legal-status Critical Current

Links

Classifications

    • 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/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0816—Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
    • H04L9/0819—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s)
    • H04L9/0825—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s) using asymmetric-key encryption or public key infrastructure [PKI], e.g. key signature or public key certificates
    • 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/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
    • H04L63/0442—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload wherein the sending and receiving network entities apply asymmetric encryption, i.e. different keys for encryption and decryption
    • 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/06—Network architectures or network communication protocols for network security for supporting key management in a packet data network
    • H04L63/062—Network architectures or network communication protocols for network security for supporting key management in a packet data network for key distribution, e.g. centrally by trusted party
    • 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/0823—Network architectures or network communication protocols for network security for authentication of entities using certificates
    • 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/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0861—Generation of secret information including derivation or calculation of cryptographic keys or passwords
    • H04L9/0866—Generation of secret information including derivation or calculation of cryptographic keys or passwords involving user or device identifiers, e.g. serial number, physical or biometrical information, DNA, hand-signature or measurable physical characteristics
    • 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/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0861—Generation of secret information including derivation or calculation of cryptographic keys or passwords
    • H04L9/0869—Generation of secret information including derivation or calculation of cryptographic keys or passwords involving random numbers or seeds
    • 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/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0894—Escrow, recovery or storing of secret information, e.g. secret key escrow or cryptographic key storage
    • 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/3263—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 certificates, e.g. public key certificate [PKC] or attribute certificate [AC]; Public key infrastructure [PKI] arrangements
    • H04L9/3265—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 certificates, e.g. public key certificate [PKC] or attribute certificate [AC]; Public key infrastructure [PKI] arrangements using certificate chains, trees or paths; Hierarchical trust model
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/12—Protocols specially adapted for proprietary or special-purpose networking environments, e.g. medical networks, sensor networks, networks in vehicles or remote metering networks

Abstract

A system comprising at least one IoT (Internet of Things) sensor, a database (DB) and one or more users connected via networks. The DB creates manufacturer and user public/private key pairs Mpub/Mpri and Upub/Upri respectively. Mpub is sent to the sensor 100/104 and Upri is sent to the user 102. Mpri and Upub are stored by the DB. The DB also stores user/sensor ownership claims. The sensor creates a first ‘readings key’ Saes (preferably a symmetrical key, preferably an AES (Advanced Encryption Standard) key) encrypts it with Mpub and transmits it to the DB 108, preferably with a sensor ID. The DB validates this message and, if successful, encrypts Upub using Saes and transmits it to the sensor 110. The sensor decrypts Upub, creates a second ‘readings key’ Raes encrypts it with Upub and transmits it to the DB 112. Subsequently sensor readings are encrypted with Raes and transmitted to the DB 114. Upon request the DB transmits the encrypted Raes and readings to the user, who decrypts Raes using Upri and thence the readings with Raes 116.

Description

DATA PROTECTION
Field of the invention
This invention relates generally to data protection and, more particularly, but not necessarily exclusively, to data protection in respect of a physical device configured to be incorporated in the Internet of Things.
Background of the Invention
The Internet of Things (loT) is a general term used to describe a network of physical devices (e.g. vehicles, home appliances and other electronic devices) embedded with electronics, software, sensors, actuators, and network connectivity which enables these devices to connect and exchange data over the internet. Such devices typically include one or more sensors communicably coupled to the Internet to enable readings to be collected and transmitted to a remote location for storage and subsequent retrieval by a user via a user terminal. Such technology is becoming increasingly widespread in many different applications, including home automation, industrial control, smart cars, medical devices, security applications and smart energy systems.
As loT continues to grow, there is an ever increasing number of interconnected devices gathering data on all aspects of our lives. However, due to the complexity and cost of implementing a secure system, these devices can often be compromised to disclose personal and private information.
loT devices can collect data from many different sources and different devices have different requirements as to the sensitivity of the data and the length of time data should be kept confidential. In addition, there may be requirement for loT devices to be authenticated and to ensure that data is not lost, changed, intercepted, forged or duplicated. This may be particularly important in smart energy, medical and security applications, for example.
Privacy of data is protected by various statutes and regulations, which vary between countries. For example, the EU General Data Protection Regulation introduces significant financial penalties in respect of companies that cause personal information to be disclosed.
Data protection and security inevitably carries a cost, and a significant level of expertise is required to implement secure solutions. There are implications for sensors, gateways, hubs, routers, cloud servers, databases and users. Many sensors are small, resource-constrained devices that are not able to handle traditional encryption and authentication methods. In many cases, the cost of implementing a security solution in an loT device is judged against the consequences of data loss. However, an issue rarely considered is the inadvertent disclosure of implicit information, rather than the data itself. For example, if a third party can intercept a command to turn on an oven in two hours time, it can be inferred, firstly, that the occupant is not currently at home, and secondly, may be home in two hours or more, thus indicating that the property is currently empty and potentially an easy target for intruders. Such inadvertent disclosure of sensitive information applies to many different types of data, including health, fitness, activity and location.
Security solutions are well established for large central servers, such as those used by banks. However, due to the complexity of the mechanisms used to protect such data, they are not usually suitable for the small, resource-constrained devices used for loT. As a result, many manufacturers of such devices fail to implement adequate security and such devices therefore suffer from security flaws such as weak authentication and encryption, default username and passwords, and poor update and patch procedures.
Nevertheless, security in such devices is becoming increasingly important, and devices having weak or no security solutions can result in a user’s privacy being compromised, potentially leading to a manufacturer suffering loss of reputation as well as financial penalties.
It is an object of aspects of the present invention to address at least some of these issues.
Summary of the Invention
In accordance with a first aspect of the present invention, there is provided a system for obtaining, storing and retrieving data collected by a sensor associated with an electronic device forming part of the Internet of Things, the system comprising:
a database module communicably coupled to a database, and comprising an input/output interface and a first processor; and a data collection module configured to be incorporated in or on a said sensor and further being configured, in use, to collect data from said sensor, said data collection module including a second processor and being located, in use, remotely from said database module, wherein said data collection module further including an input/output interface configured, in use, to be communicably coupled to said input/output interface of said database module;
wherein, in use:
said first processor generates, upon request, a first public/private key pair (MPUB/MPRI) in respect of a manufacturer of a said sensor, stores the private key thereof (MPRI) in said database module, and transmits the public key thereof (MPUB) to the data collection module in or on said sensor;
said first processor generates, upon request by a user of an electronic device with which said sensor is associated, a second public/private key pair (UPUB/UPRI), stores the public key thereof (UPUB) in said database module, and transmits the private key thereof (UPRI) to a user terminal, said database module being configured to store in the database associated therewith, data representing a user claiming ownership of said sensor against identification data representative thereof;
said second processor generates a first readings key (SAES), encrypts said first readings key with said public key (MPUB) of said first public/private key pair, and transmits said encrypted first readings key to said database module;
said first processor obtains the public key (UPUB) of said second public/private key pair, encrypts it with said first readings key (SAES), and transmits said encrypted public key to the data collection module;
said second processor generates a second readings key (RAES), encrypts it with said public key (UPUB) of said second public/private key pair, and transmits the encrypted second readings key to said database module, wherein said first processor stores the said encrypted second readings key UPUB(RAES) in the database associated with said sensor;
said data collection module collects data from said sensor, said second processor encrypts the collected data with said second readings key (RAES) and transmits the encrypted collected data to the database module for storage in said database together with the associated said encrypted second readings key UPUB(RAES);
wherein, upon request, said database module retrieves said encrypted collected data and said encrypted second readings key from said database and transmits it to a said user terminal, whereupon a processor of said user terminal can decrypt said second readings key (RAES) using said private key (UPRI) of said second public/private key pair and use the decrypted second readings key (RAES) to decrypt said collected data.
In a preferred exemplary embodiment of the invention, all data, encrypted with a said public key and transmitted between said database module and said data collection module and or a user terminal, is further encrypted using said first readings key (SAES).
In an exemplary embodiment, the database module may be configured to store, in said database, registration data representative of a plurality of data collection modules of each of a plurality of respective sensors originating from said manufacturer. Optionally, the registration data may comprise a unique identifier associated with a respective data collection module and/or a respective serial number. Thus, the user may claim ownership, within said database module, of a sensor by registering a respective said serial number and/or unique identifier against a user account predefined within said database module. The data collection module may be configured, when it is powered on, to determine if any keys are stored therein and, if it detects that no keys are stored therein, prompt or otherwise cause said user or a respective user terminal to register said data collection module or associated sensor in said user account predefined within said database module.
In a preferred exemplary embodiment, one or more of said keys can be selectively and/or randomly re-set.
Optionally, the first and/or second public/private key pairs may be generated using an RSA algorithm; and/or the first and/or second readings keys may be generated using an AES encryption algorithm.
In accordance with a second aspect of the present invention, there is provided a method for obtaining, storing and retrieving data collected by a sensor associated with an electronic device forming part of the Internet of Things, the system comprising:
providing a database module communicably coupled to a database, and comprising an input/output interface and a first processor;
providing a data collection module configured to be incorporated in or on a said sensor and further being configured, in use, to collect data from said sensor, said data collection module including a second processor and being located, in use, remotely from said database module, wherein said data collection module further including an input/output interface configured, in use, to be communicably coupled to said input/output interface of said database module;
using said first processor to generate, upon request, a first public/private key pair (MPUB/MPRI) in respect of a manufacturer of a said sensor, store the private key thereof (MPRI) in said database module, and transmit the public key thereof (MPUB) to the data collection module in or on said sensor;
using said first processor to generate, upon request by a user of an electronic device with which said sensor is associated, a second public/private key pair (UPUB/UPRI), store the public key thereof (UPUB) in said database module, and transmit the private key thereof (UPRI) to a user terminal;
said database module being configured to store in the database associated therewith, data representing a user claiming ownership of said sensor against identification data representative thereof;
using said second processor to generate a first readings key (SAES), encrypt said first readings key with said public key (MPUB) of said first public/private key pair, and transmit said encrypted first readings key to said database module;
using said first processor to obtain the public key (UPUB) of said second public/private key pair, encrypt it with said first readings key (SAES), and transmit said encrypted public key to the data collection module;
using said second processor to generate a second readings key (RAES), encrypt it with said public key (UPUB) of said second public/private key pair, and transmit the encrypted second readings key to said database module, wherein; said first processor stores the said encrypted second readings key UPUB(RAES) in the database associated with said sensor;
using data collection module to collect data from said sensor, and using said second processor to encrypt the collected data with said second readings key (RAES) and transmit the encrypted collected data to the database module for storage in said database together with the associated said encrypted second readings key UPUB(RAES) ;
using said data collection module to collect data from said sensor, and using said second processor to encrypt the collected data with said public key (UPUB) of said second public/private key pair and transmit the encrypted collected data and the encrypted second readings key to the database module for storage in said database;
wherein, upon request, said database module can retrieve said encrypted collected data and said encrypted second readings key from said database and transmit it to a said user terminal, whereupon a processor of said user terminal can decrypt said second readings key (RAES) using said private key (UPRI) of said second public/private key pair and use the decrypted second readings key (RAES) to decrypt said collected data.
In accordance with a third aspect of the present invention, there is provided a database module for a system substantially as described above, communicably coupled to a database and comprising said first processor and an input/output interface configured to be communicably coupled to the input/output interface of a data collection module in or on a remote sensor, said database module being configured to store, in said database, a user account comprising data representing a user claiming ownership of said remote sensor against identification data representative thereof, wherein said first processor is configured to:
generate, upon request, said first public/private key pair (MPUB/MPRI), store the private key thereof (MPRI) and transmit the public key thereof (MPUB) to said data collection module;
generate, upon request by said user, a second public/private key pair (UPUB/UPRI), store the public key thereof (UPUB) and transmit the private key thereof to said user account and/or a user terminal;
receive, from said data collection module, and store an encrypted first readings key (SAES);
obtain said public key (UPUB) of said second public/private key pair, encrypt said first readings key (SAES) therewith, and transmit said encrypted public key to said data collection module;
receive, from said data collection module, a second readings key (RAES) encrypted with said public key (UPUB) of said second public/private key pair and store said encrypted second readings key;
receive data from said data collection module, said data comprising readings collected from said sensor and encrypted with said public key (UPUB) of said second public/private key pair, and store said data in said database; and upon request by said user, retrieve and transmit said data and said encrypted second readings key to said user terminal.
Optionally, all data, encrypted with a said public key and transmitted between said first processor and said data collection module and/or said user terminal, is further encrypted with said first readings key (SAES) prior to transmission thereof.
According to a fourth aspect of the present invention, there is provided a data collection module for a system substantially as described above, configured to be communicably coupled to a local sensor and to a remote database module substantially as described above, the data collection module comprising a second processor and an input/output interface, the second processor being configured to:
receive and store the public key (MPUB) of said first public/private key pair;
generate said first readings key (SAES), encrypt said first readings key with said public key (MPUB) of said first public/private key pair, and transmit said encrypted first readings key to said database module;
receive, from said database module, an encrypted public key (UPUB) of a second public/private key pair, said public key (UPUB) being encrypted with said first readings key (SAES);
generate a second readings key (RAES), encrypt said second readings key with said public key (UPUB) of said second public/private key pair, and transmit the encrypted second readings key to said database module; and receive data representative of readings collected by said sensor, encrypt said data with said public key (UPUB) of said second public/private key pair and transmit the encrypted data to said database module for storage.
It is to be understood that the system, method, database module and/or the data collection module can be implemented with suitable software and/or hardware, as will be apparent to a person skilled in the art, and the present invention is not necessarily intended to be limited in this regard. Nevertheless, in a preferred embodiment of the above-described system, the database module may be software implemented on a server hosted by a central body or organisation, and the database may be implemented in the cloud, whereas the data collection module, which may also be software implemented, may comprise a stand-alone platform that can be incorporated into a said electronic device and communicably coupled to the sensor thereof (at the time of manufacture or otherwise).
These and other aspects of the present invention will be apparent from the following specific description.
Brief Description of the Drawings
An embodiment of the present invention will now be described, by way of example only, and with reference to the accompanying drawings, in which:
Figure 1 is a schematic illustration of a system according to an exemplary embodiment of the present invention; and
Figure 2 is a flow diagram illustrating principal steps of a method according to an exemplary embodiment of the present invention.
Detailed Description
From an implementation stand point, a secure service for exchanging loT data should, ideally, provide an effective method of authentication and encryption. A central body or organisation may act as a Certificate Authority to issue certificates to users and manufacturers. RSA may then be used to exchange AES keys between sensors, the central body or organisation, manufacturers and users. These AES keys can be used to encrypt data communications between sensors and the central body or organisation, between sensors and the database, and between the database and an end user. The careful use of encryption and authentication in then following exemplary embodiment of the present invention serve to protect the confidentiality, integrity and availability of data.
As will be known to a person skilled in the art, RSA is an asymmetric encryption method that utilises two keys, namely a private key (PRI) and a public key (PUB). One of the keys of the pair is used encrypt data and the other is used to decrypt the data (i.e. the key that is used encrypt the data cannot be used to decrypt the same data). In normal use, data is encrypted using the recipient’s public key and only that recipient can decrypt the data using their own private key. It is also possible to encrypt data using the private key, and the data can then only be decrypted using the corresponding public key, thereby providing a method of signing the data. The public keys do not need to be secret and are therefore published.
RSA could, in theory, be used to encrypt all messages/data in one exemplary embodiment of the present invention. However, whilst highly secure, it is a complex mathematical process, and is therefore slow and requires significant computational power. Therefore, in the exemplary embodiment described below, RSA is not used to encrypt all messages, but instead is just used to securely exchange an AES key and the AES key is then used for future communications.
AES is a symmetric key, in the sense that the same key is used to encrypt and decrypt data. Key lengths can be 128 or 256 bits long, bearing in mind that 256 bits is the US Government Top Secret level (military grade). Implementation algorithms are common in both hardware and software and, as will be known to a person skilled in the art, AES is selected for many encryption implementations. A weakness of AES is that, in its basic form, it does not handle encryption of repeated data as it generates a pattern that makes it easier to break. Sensor data, in the exemplary embodiment described below, is necessarily going to be often repeated, so, to circumvent this problem, AES can be used for long individual messages using CBC (block chaining) and can be used for many individual messages by using an initialisation vector. Both of these methods are implemented in the exemplary embodiment described below.
A requirement for AES key exchange using RSA is that the identity of the other party is verified before exchanging a key with them. This is done internally in the exemplary embodiment described below, using certificates issued by a central body or organisation as a Certificate Authority. In circumstances where the central body or organisation needs to connect or communicate with a third party system, it may use certificates issued by a Public Key Authority (similar to the manner in which certificates are issued to websites to allow them to provide HPPTS security). The issuing authority verifies identities before issuing certificates and can revoke those certificates if they are compromised.
Thus, an object of at least one exemplary embodiment of the present invention, to be implemented in respect of an loT device, is to secure all data so that it can only be accessed by the authorised owner.
For true end-to-end encryption, the data should be encrypted in the sensor and not decrypted until it is delivered to the user (i.e. the authorised owner of the data collected by the sensor). This causes many implementation issues, which the following exemplary embodiment of the invention seeks to overcome, namely:
• Authentication of sensors and respective (authorised) users • Management and exchange of encryption keys • Changing of keys on a random and frequent basis • Encryption of data at rest in the database • How to manage data encrypted with multiple sensor and user keys • Encryption and decryption process • Efficient processing of data • Data belonging to multiple users • How to keep data confidential from the central body or organisation and associated service
The concept of true end-to end encryption is illustrated schematically in Figure 1 of the drawings. As shown, a typical implementation of an exemplary embodiment of the invention comprises a sensor 10 incorporated in an electronic device and configured to take readings or otherwise collect data from the electronic device. A security module incorporated in the sensor 10 is wirelessly coupled to a database module 12 hosted at a remote location by a central body or organisation. A user 14a, if they are the authorised owner of the data collected by the sensor 10, can access the data via a user terminal 14b, which is also wirelessly coupled to the database module 12. As illustrated schematically, the user/user terminal (14a/14b) is authenticated by the database module 12, and the data collected by the sensor 10 is encrypted, both for transmission to the database module 12 and for storage therein. A security module according to an exemplary embodiment of the present invention, incorporated in the sensor 10, provides code libraries for multiple platforms. The user terminal 14b is provided with access to code libraries and web extensions. Data storage may be implemented in the cloud 16, which helps to make the overall system reliable, responsive, secure and scalable, and the database itself is secured and stores only encrypted data.
Referring to Figure 2 of the drawings, in a system according to an exemplary embodiment of the present invention, the manner of operation is as follows:
Step 100 The manufacturer registers with the system to obtain a Public/Private key pair (MPUB and MPRI). MPUB, which does not have to be kept confidential, is issued to the manufacturer. MPRI, which must be kept confidential, is retained in the database module hosted by the central body or organisation.
Step 102 A user registers with the system to obtain a Public/Private key pair (UPUB and UPRI). UPRI, which must be kept confidential, is issued to the user’s account (accessible, upon successful authentication, via a user terminal). UPUB is retained in the database module hosted by the central body or organisation. In order to generate the user keys (UPUB and UPRI), a special feature available in internet browsers (on the user terminal 14b - Figure 1) may be used to generate the random codes on which UPUB and UPRI are based. This ensures that the database module only ‘knows’ UPUB and never has access to UPRI.
Step 104 The manufacturer places a copy of MPUB in the security module incorporated in each sensor or device they manufacture. They also register each sensor or device with the database module (12- Figure 1). Such registration may, for example, comprise the sensor ID (DID) and the sensor serial number (SERNO).
Step 106 When the sensor (10 - Figure 1) is powered on, its security module checks if it has any keys and, if not,
Step 108 it registers with the database module by reading the sensor device ID (DID), generating a first readings AES key (SAES), and encrypting the sensor ID and the first readings key with the manufacturer’s public key (MPUB), before transmitting the encrypted data to the database module.
Step 110 The database module checks the database for a valid sensor and a valid user and, only if both are valid, it reads the user public key (UPUB), encrypts it with the first readings key (SAES) and transmits the encrypted key back to the security module incorporated in the sensor.
Step 112 The security module in the sensor then generates a second readings AES key (RAES) (which will be used by the security module to encrypt readings obtained from the sensor), encrypts it with the user’s public key (UPUB), and transmits the encrypted key to the database module.
At this stage, the security module in the sensor has an AES key (RAES) which is used to encrypt sensor readings. This key is not ‘known’ to the database module in its plaintext form, only in the encrypted form (encrypted with UPUB). In addition, the security module and the database module both ‘know’ an AES key (SAES) which is used to further encrypt all communications between them.
Step 114 When the sensor has a reading, the security module encrypts it using the user’s public key (UPUB) readings AES key (RAES) and sends it (further encrypted with SAES) to the database module. The database module causes this encrypted reading to be stored in the database together with the readings AES key (RAES) in its encrypted form (with UPUB).
Step 116 When the user retrieves information from the database, the user retrieves the encrypted key (encrypted RAES), decrypts it using their private key (UPRI), and then the decrypted readings key (RAES) can be used to decrypt the reading for access via the user terminal.
It will be understood that the keys referenced in the method described above can be changed at any time, including upon request from the database module, on sensor power-off and/or randomly.
It can, therefore, be seen that the database module provides end to end security for the Internet of Things. This is from the sensor itself (sometimes referred too as the edge node) through to the user when they retrieve their data. The data is always encrypted including in transit and at rest in the database.
The database module provides encryption and therefore has to manage and exchange keys, this also requires authentication of sensors and users to ensure that keys are only provided to the correct entities.
To ensure security, and allow the use of smaller keys, it is preferable (or even necessary) to change keys on a frequent and random basis - fixed and unchangeable keys are one of the greatest sources of insecurity.
However, if data is not to be decrypted at any point then there must be a method of recording the key used to encrypt each piece of data as data for any individual user may be encrypted with a different key.
The means by which this is accomplished in accordance with the present invention is considered to be a highly innovative process with real world benefit - the security and protection of data for an individual user.
One of the key steps in the above-described method is where the User who owns the data is issued with a Public/Private key pair and each piece of data stored in the database is encrypted and the key used to encrypt the data is further encrypted with the Users Public key. The only way to retrieve the data is to first decrypt the readings key (RAES) using the Users Private key (which is confidential and available only to an authenticated user).
The additional steps in the process is to provide a method of exchanging keys such that the key used to encrypt the data is never known by the system in unencrypted form and therefore the data is only ever accessible by the registered owner.
An implementation protocol in respect of the above-described method is provided below:
Register -> {database module: register, id: DID,data:registration- 1
Registration-data =
<- {id: DID, iv: iv,data: response} 2
response = {SAES(id:DID,upub:UPUB)}
-> {id:DID,iv:iv,data:key-data} 3
key-data = {SAES(id:DID,data:UPUB(RAES))}
<- {id: DID, iv: iv,data: response} 4
response = {SAES(id:DID,response:registered)}
Data -> {database 5
readings-data = {SAES(id:DID,iv:iv,msg:message-number,data:readings)} readings = {RAES(list-of-readings)} <- {id:DID,iv:iv,data:response} 6 response = {SAES(id:DID,response:response)} response = OK/ERROR/KEYCHANGE/COMMAND
Thus (wherein SENSOR is used to refer to the security module incorporated in the sensor):
1.a SENSOR generates SAES key to be used for encrypting data between SENSOR and DATABASE MODULE .b SENSOR calculates SHA for installed SENSOR code
1.c Device ID (DID), SHA code and SAES key are encrypted using the Manufacturer’s
Public key stored in the Sensor (MPUB)
1. d Data packet is sent to Database module
2. a Database module responds with a confirmation
2. b SENSOR receives a packet encrypted with SAES which contains the device ID and the User’s Public key (UPUB)
3. a SENSOR generates RAES key to be used for encrypting readings
3.b SENSOR encrypts RAES with the Users Public key (UPUB)
3.c Device ID (DID) and encrypted RAES key are encrypted with SAES
3. d Data packet is sent to Database module
4. a Database module responds with a confirmation
4. b SENSOR receives a packet encrypted with SAES which contains a confirmation
5. a SENSOR takes a reading, generates a random Readings IV (RIV), the Device ID (DID) and encrypts the reading with RAES
5. b The Device ID (DID), Readings Initialisation Vector (RIV), Sequential Message Number and the encrypted readings are all encrypted using SAES and a random Session Initialisation Vector (SIV)
The Device ID (DID), Session Initialisation Vector (SIV), and the packet described in 5.b are sent to Database module where they are stored in the database. The readings are stored in their original encrypted form and the encrypted RAES key is also stored.
6. a Database module responds
6.b The response can be a simple data response (eg OK or ERROR), can be a key change request (the RAES and SAES keys are deleted so that the SENSOR will re- register), or can be a command response particular to the SENSOR which is passed back to the device to be actioned.
The above-described sequence has a number of key features:
1. The SENSOR does not need a unique manufacturing process as long as the device contains a unique ID. This is a common feature found in most - if not all microprocessors. The SHA code generated as a hash code for the installed software acts as an additional SENSOR identification.
2. The SENSOR can communicate with the database module using the Manufacturers Public key to encrypt data. A key feature of Public/Private communication used by RSA is that it gives the ability for many devices to communicate with a central point without having to exchange keys
3. By including a calculated SHA checksum for the installed code, the database module can verify code integrity in the SENSOR to ensure that the codebase has not been tampered with
4. The AES key used to encrypt readings is generated in the SENSOR
5. Keys generated in the SENSOR may, for example, be 128bit AES keys. These keys only have to be random numbers, they do not need the same standard of entropy based cryptographic randomness as RSA keys. They are also much smaller (128 bits rather than 2048 bits), thus optimizing the speed and processing power required to implement the system.
6. The readings key (RAES) is encrypted before it is sent so that it is never known to the database module. The key used to encrypt RAES is the User’s Public key so only an authenticated user, in possession of their Private key, can decrypt it
7. Following the registration process (using RSA keys), all encryption is performed using AES. Separate keys are used for communications between the SENSOR and the database module and for encryption of Readings. This ensures that all communications are confidential and that even the database module does not have access to the User’s data
8. When Readings data is stored in the database in encrypted form, the key (in encrypted form) is also stored in association therewith.
9. The readings key can be changed at any time for each Sensor. This includes when the Sensor is reset, when it is rebooted, and at any random time requested by the database module server, for example. This significantly increases the security of the data in the database as it will have been encrypted by many different keys.
10. If the protocol detects any anomalies, or if data does not decrypt correctly then the packet is discarded. No response is sent so that no protocol analysis is available to any intruder. In addition, the SHA checksum is used to validate code integrity
11. Readings can be acknowledged and/or receive a command response. In this case the action is returned to the device to be actioned.
Thus, the present invention seeks to address at least some of the problems described above in relation to current loT devices by providing a cost-effective secure solution for protecting sensor data collected within loT devices in many different applications and fields. Data is encrypted in the sensor and stored in encrypted form in the database. Upon retrieval, the data can only be decrypted by the user with their private key. To support the described solution, key management provides a method of issuing keys to sensors and users so that data can be encrypted and decrypted. Keys can be revoked and reissued to further increase security and at no point is data in an unencrypted form, thereby providing privacy and confidentiality at all times. The described embodiment is robust and scalable and may be hosted in the cloud, which provides unlimited storage capacity. State of the art encryption and authentication methods may be used to provide confidentiality, integrity and availability of all data.
The described solution can be provided to manufacturers to be included in their product so that they do not have to design their own solutions, and to provide a user friendly infrastructure platform which the device manufacturer can conveniently use. The database is hosted in the cloud and holds data securely. For a web or smart phone application, the platform may additionally include code that allows information to be retrieved from the cloud as required. In use, all information is fully encrypted and the sensor and the server are both authenticated. Within the system, data is held in encrypted form and only the registered owner holds the key that enables access to it. As stated above, this ensures confidentiality, integrity and availability (to the user) of data at all times.
Key features can be summarised as follows:
User Identification and Authentication
Manufacturer Identification and Authentication
Manufacturer registers Sensors
Sensor configuration and registration
Sensor requests an encryption key
Dynamic revocation
Sensing of readings and receipt of commands
Storage of sensor readings
Retrieval of stored readings [User registers on the system and is issued with a PKI certificate] [Manufacturer registers on the system and is issued with a PKI certificate] [Manufacturer registers each sensor on the database as a valid sensor] [Sensor registers automatically and is associated with a user] [System authenticates the sensor and issues an encryption key] [Unique sensor keys can be revoked and reissued at any time] [Bi-directional encrypted data between system and sensor] [Data stored in encrypted form accessible to registered user] [Only the registered user has the unlock keys for retrieval]
It will be appreciated by a person skilled in the art, from the foregoing description, that modifications and variations can be made to the described embodiment without departing from the scope of the invention as defined by the appended claims.

Claims (13)

1. A system for obtaining, storing and retrieving data collected by a sensor associated with an electronic device forming part of the Internet of Things, the system comprising:
- a database module communicably coupled to a database, and comprising an input/output interface and a first processor; and
- a data collection module configured to be incorporated in or on a said sensor and further being configured, in use, to collect data from said sensor, said data collection module including a second processor and being located, in use, remotely from said database module, wherein said data collection module further includes an input/output interface configured, in use, to be communicably coupled to said input/output interface of said database module;
and wherein, in use:
- said first processor generates, upon request, a first public/private key pair (MPUB/MPRI) in respect of a manufacturer of a said sensor, stores the private key thereof (MPRI) in said database module, and transmits the public key thereof (MPUB) to the data collection module in or on said sensor;
- said first processor generates, upon request by a user of an electronic device with which said sensor is associated, a second public/private key pair (UPUB/UPRI), stores the public key thereof (UPUB) in said database module, and transmits the private key thereof (UPRI) to a user terminal; said database module is configured to store in the database associated therewith, data representing a user claiming ownership of said sensor against identification data representative thereof;
- said second processor generates a first readings key (SAES), encrypts said first readings key with said public key (MPUB) of said first public/private key pair, and transmits said encrypted first readings key to said database module;
- said first processor obtains the public key (UPUB) of said second public/private key pair, encrypts it with said first readings key (SAES), and transmits said encrypted public key to the data collection module;
- said second processor generates a second readings key (RAES), encrypts it with said public key (UPUB) of said second public/private key pair, and transmits the encrypted second readings key to said database module;
- said data collection module collects data from said sensor, said second processor encrypts the collected data with said second readings key (RAES) and transmits the encrypted collected data and the encrypted second readings key to the database module for storage in said database; wherein, upon request, said database module retrieves said encrypted collected data and said encrypted second readings key from said database and transmits it to a said user terminal, whereupon a processor of said user terminal can decrypt said second readings key (RAES) using said private key (UPRI) of said second public/private key pair and use the decrypted second readings key (RAES) to decrypt said collected data.
2. A system according to claim 1, wherein all data, encrypted with a said public key and transmitted between said database module and said data collection module, is further encrypted using said first readings key (SAES).
3. A system according to claim 1 or claim 2, wherein said database module is configured to store, in said database, registration data representative of a plurality of data collection modules of each of a plurality of respective sensors originating from said manufacturer.
4. A system according to claim 3, wherein said registration data comprises a unique identifier associated with a respective data collection module and/or a respective serial number.
5. A system according to claim 4, wherein a user can claim ownership, within said database module, of a sensor by registering a respective said serial number and/or unique identifier against a user account predefined within said database module.
6. A system according to claim 5, wherein said data collection module is configured, when it is powered on, to determine if any keys are stored therein and, if it detects that no keys are stored therein, prompt or otherwise cause said user or a respective user terminal to register said data collection module or associated sensor in said user account predefined within said database module.
7. A system according to any of the preceding claims, wherein one or more of said keys can be selectively and/or randomly re-set.
8. A system according to any of the preceding claims, wherein the first and/or second public/private key pairs are generated using an RSA algorithm.
9. A system according to any of the preceding claims, wherein said first and/or second readings keys are generated using an AES encryption algorithm.
10. A method for obtaining, storing and retrieving data collected by a sensor associated with an electronic device forming part of the Internet of Things, the system comprising:
- providing a database module communicably coupled to a database, and comprising an input/output interface and a first processor;
- providing a data collection module configured to be incorporated in or on a said sensor and further being configured, in use, to collect data from said sensor, said data collection module including a second processor and being located, in use, remotely from said database module, wherein said data collection module further including an input/output interface configured, in use, to be communicably coupled to said input/output interface of said database module;
- using said first processor to generate, upon request, a first public/private key pair (MPUB/MPRI) in respect of a manufacturer of a said sensor, store the private key thereof (MPRI) in said database module, and transmit the public key thereof (MPUB) to the data collection module in or on said sensor;
- using said first processor to generate, upon request by a user of an electronic device with which said sensor is associated, a second public/private key pair (UPUB/UPRI), store the public key thereof (UPUB) in said database module, and transmit the private key thereof (UPRI) to a user terminal;
said database module being configured to store in the database associated therewith, data representing a user claiming ownership of said sensor against identification data representative thereof;
- using said second processor to generate a first readings key (SAES), encrypt said first readings key with said public key (MPUB) of said first public/private key pair, and transmit said encrypted first readings key to said database module;
- using said first processor to obtain the public key (UPUB) of said second public/private key pair, encrypt it with said first readings key (SAES), and transmit said encrypted public key to the data collection module;
- using said second processor to generate a second readings key (RAES), encrypt it with said public key (UPUB) of said second public/private key pair, and transmit the encrypted second readings key to said database module;
- using said data collection module to collect data from said sensor, and using said second processor to encrypt the collected data with said second readings key (RAES) and transmit the encrypted collected data and the encrypted second readings key to the database module for storage in said database;
wherein, upon request, said database module can retrieve said encrypted collected data and said encrypted second readings key from said database and transmit it to a said user terminal, whereupon a processor of said user terminal can decrypt said second readings key (RAES) using said private key (UPRI) of said second public/private key pair and use the decrypted second readings key (RAES) to decrypt said collected data.
11 .A database module for a system according to any of claims 1 to 9, communicably coupled to a database and comprising said first processor and an input/output interface configured to be communicably coupled to the input/output interface of a data collection module in or on a remote sensor, said database module being configured to store, in said database, a user account comprising data representing a user claiming ownership of said remote sensor against identification data representative thereof, wherein said first processor is configured to:
- generate, upon request, said first public/private key pair (MPUB/MPRI), store the private key thereof (MPRI) and transmit the public key thereof (MPUB) to said data collection module;
- generate, upon request by said user, a second public/private key pair (UPUB/UPRI), store the public key thereof (UPUB) and transmit the private key thereof to said user account and/or a user terminal;
- receive, from said data collection module, and store an encrypted first readings key (SAES);
- obtain said public key (UPUB) of said second public/private key pair, encrypt said first readings key (SAES) therewith, and transmit said encrypted public key to said data collection module;
- receive, from said data collection module, a second readings key (RAES) encrypted with said public key (UPUB) of said second public/private key pair and store said encrypted second readings key;
- receive data from said data collection module, said data comprising readings collected from said sensor and encrypted with said second readings key (RAES) and store said data in said database; and
- upon request by said user, retrieve and transmit said data and said encrypted second readings key to said user terminal.
12. A database module according to claim 11, wherein all data, encrypted with a said public key and transmitted between said first processor and said data collection module and/or said user terminal, is further encrypted with said first readings key (SAES) prior to transmission thereof.
13. A data collection module for a system according to any of claims 1 to 9, configured to be communicably coupled to a local sensor and to a remote database module according to claim 11, the data collection module comprising a second processor and an input/output interface, the second processor being configured to:
- receive and store the public key (MPUB) of said first public/private key pair;
- generate said first readings key (SAES), encrypt said first readings key with said public key (MPUB) of said first public/private key pair, and transmit said encrypted first readings key to said database module;
- receive, from said database module, an encrypted public key (UPUB) of a second public/private key pair, said public key (UPUB) being encrypted with said first readings key (SAES);
- generate a second readings key (RAES), encrypt said second readings key with said public key (UPUB) of said second public/private key pair, and transmit the encrypted second readings key to said database module; and
- receive data representative of readings collected by said sensor, encrypt said data with second readings key (RAES) and transmit the encrypted data to said database module for storage.
Intellectual Property Office
Application No: GB1800469.7
Claims searched: 1,10
GB1800469.7A 2018-01-11 2018-01-11 Data protection Withdrawn GB2570292A (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
GB1800469.7A GB2570292A (en) 2018-01-11 2018-01-11 Data protection

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
GB1800469.7A GB2570292A (en) 2018-01-11 2018-01-11 Data protection

Publications (2)

Publication Number Publication Date
GB201800469D0 GB201800469D0 (en) 2018-02-28
GB2570292A true GB2570292A (en) 2019-07-24

Family

ID=61256280

Family Applications (1)

Application Number Title Priority Date Filing Date
GB1800469.7A Withdrawn GB2570292A (en) 2018-01-11 2018-01-11 Data protection

Country Status (1)

Country Link
GB (1) GB2570292A (en)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11233632B1 (en) 2020-07-02 2022-01-25 Cal-Chip Electronics Specialty Products, Inc. Connected secure key redistribution system and method

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
Menezes A J et al, Handbook of Applied Cryptography , 5th Printing, August 2001, CRC Press *

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11233632B1 (en) 2020-07-02 2022-01-25 Cal-Chip Electronics Specialty Products, Inc. Connected secure key redistribution system and method

Also Published As

Publication number Publication date
GB201800469D0 (en) 2018-02-28

Similar Documents

Publication Publication Date Title
KR101851261B1 (en) Centralized remote metering system for security based on private block-chained data
EP3090520B1 (en) System and method for securing machine-to-machine communications
JP6976949B2 (en) Methods and systems for key distribution between servers and medical devices
US6732270B1 (en) Method to authenticate a network access server to an authentication server
US8407477B2 (en) Information distribution system and program for the same
KR101753859B1 (en) Server and method for managing smart home environment thereby, method for joining smart home environment and method for connecting communication session with smart device
CN105530253B (en) Wireless sensor network access authentication method under Restful framework based on CA certificate
KR101686167B1 (en) Apparatus and Method for Certificate Distribution of the Internet of Things Equipment
JP2009529832A (en) Undiscoverable, ie secure data communication using black data
JP6644037B2 (en) Communication control system
US20210167963A1 (en) Decentralised Authentication
US11917081B2 (en) Issuing device and method for issuing and requesting device and method for requesting a digital certificate
Dua et al. Replay attack prevention in Kerberos authentication protocol using triple password
CN112671735B (en) Data encryption sharing system and method based on block chain and re-encryption
US20230038949A1 (en) Electronic signature system and tamper-resistant device
Chen et al. Enhanced authentication protocol for the Internet of Things environment
EP4203377A1 (en) Service registration method and device
CN111740995B (en) Authorization authentication method and related device
US10764260B2 (en) Distributed processing of a product on the basis of centrally encrypted stored data
GB2570292A (en) Data protection
US11522842B2 (en) Central trust hub for interconnectivity device registration and data provenance
CN113545025A (en) Method and system for information transmission
CN116471081B (en) Indoor security anonymous authentication method based on Internet of things technology
JP7042853B2 (en) Client-side communication control device and server-side communication control device
CN116599771B (en) Data hierarchical protection transmission method and device, storage medium and terminal

Legal Events

Date Code Title Description
WAP Application withdrawn, taken to be withdrawn or refused ** after publication under section 16(1)