Decentralised Authentication

Abstract

First and second devices store respective device data and private keys. The first-device data is additionally stored by the second device and by a proxy; and the second-device data is additionally stored by the first device and by the proxy. In a commitment phase, each of the first and second devices uses its respective device data, private key and a random nonce to generate a one-time first-device commitment value, which it sends to the proxy. In a checking phase, the devices communicate secret-key information to the proxy, which verifies the received one-time commitment values. In a digest phase, the proxy calculates a one-time digest, which it sends to the second device. The second device (101) then verifies the received one-time digest to authenticate the first device.

Claims

1. A method for authenticating a first device to a second device using a proxy, wherein: the first device stores first-device data and a first-device private key; the second device stores second-device data and a second-device private key; the first-device data is additionally stored by the second device and by the proxy; and the second-device data is additionally stored by the first device and by the proxy, the method comprising, in a commitment phase: the first device using the first-device data and first-device secret-key information to generate a one-time first-device commitment value, the first-device secret-key information comprising, or being derived from, the first-device private key and a first random nonce; the first device sending the one-time first-device commitment value to the proxy; the second device using the second-device data and second-device secret-key information to generate a one-time second-device commitment value, the second-device secret-key information comprising, or being derived from, the second-device private key and a second random nonce; the second device sending the one-time second-device commitment value to the proxy, the method further comprising, in a checking phase performed after the commitment phase: the first device communicating the first-device secret-key information to the proxy; the second device communicating the second-device secret-key information to the proxy; the proxy using the first-device data stored by the proxy, and the first-device secret-key information received from the first device, to verify the one-time first-device commitment value received from the first device; and the proxy using the second-device data stored by the proxy, and the second-device secret-key information received from the second device, to verify the one-time second-device commitment value received from the second device; the method further comprising, in a digest phase, performed after a successful verification of the one-time first-device commitment value and of the one-time second-device commitment value in the commitment phase: the proxy calculating a one-time digest from i) the first-device data stored by the proxy, ii) the second-device data stored by the proxy, iii) the first-device secret-key information received from the first device, and iv) the second-device secret-key information received from the second device; the proxy sending the one-time digest to the second device; and the second device authenticating the first device by using at least i) the first-device data stored by the second device, ii) the second-device data stored by the second device, iii) the first-device secret-key information received from the first device, and iv) the second-device secret-key information, to verify the one-time digest received from the proxy.

2. The method of claim 1, wherein the method further comprises the proxy sending the one-time digest to the first device, and the first device authenticating the second device by using at least i) the first-device data stored by the first device, ii) the second-device data stored by the first device, iii) the first-device secret-key information, and iv) the second-device secret-key information received from the second device, to verify the one-time digest received from the proxy.

3. The method of claim 1, wherein the first device and the second device verify one or more one-time commitment values, in addition to the verification of the one-time first-device and second-device commitment values performed by the proxy.

4. The method of claim 1, wherein the proxy stores proxy data and a proxy-device private key and wherein the method further comprises the proxy using the proxy data and proxy-device secret-key information to generate a one-time proxy-device commitment value, the proxy-device secret-key information comprising, or being derived from, the proxy-device private key and a third random nonce.

5. The method of claim 4, wherein the second device stores the proxy data and the proxy-device private key, the method further comprising: the proxy sending the one-time proxy device commitment value to the second device; the proxy communicating the proxy-device secret-key information to the second device; and the second device using the proxy data stored in the second device and the proxy-device secret key information received from the proxy device to verify the one-time proxy-device commitment value received from the proxy device.

6. The method of claim 5, comprising: the proxy additionally using the proxy data and the proxy-device secret key information to calculate the one-time digest value; and the second device additionally using the proxy data stored by the second device, and the proxy-device secret-key information received from the proxy device, to verify the one-time digest received from the proxy, when authenticating the first device.

7. The method of claim 4, wherein the first device stores the proxy data and the proxy-device private key, the method further comprising: the proxy sending the one-time proxy device commitment value to the first device; the proxy communicating the proxy-device secret-key information to the first device; and the first device using the proxy data stored in the first device, and the proxy-device secret key information received from the proxy device, to verify the one-time proxy-device commitment value received from the proxy device.

8. The method of claim 7, comprising: the proxy additionally using the proxy data and the proxy-device secret key information to calculate the one-time digest value; and the first device additionally using the proxy data stored by the first device, and the proxy-device secret-key information received from the proxy device, to verify the one-time digest received from the proxy, when authenticating the second device.

9. A communication system comprising: a first device; a second device; and a proxy device, wherein: the first device stores first-device data and a first-device private key; the second device stores second-device data and a second-device private key; the first-device data is additionally stored by the second device and by the proxy device; and the second-device data is additionally stored by the first device and by the proxy device, wherein the first device is configured, in a commitment phase, to: use the first-device data and first-device secret-key information to generate a one-time first-device commitment value, the first-device secret-key information comprising, or being derived from, the first-device private key and a first random nonce; and send the one-time first-device commitment value to the proxy device, wherein the second device is configured, in the commitment phase, to: use the second-device data and second-device secret-key information to generate a one-time second-device commitment value, the second-device secret-key information comprising, or being derived from, the second-device private key and a second random nonce; and send the one-time second-device commitment value to the proxy device, wherein: the first device is configured, in a checking phase, performed after the commitment phase, to communicate the first-device secret-key information to the proxy device; the second device is configured, in the checking phase, to communicate the second-device secret-key information to the proxy device; the proxy device is configured, in the checking phase, to use the first-device data stored by the proxy device, and the first-device secret-key information received from the first device, to verify the one-time first-device commitment value received from the first device; and the proxy device is further configured, in the checking phase, to use the second-device data stored by the proxy device, and the second-device secret-key information received from the second device, to verify the one-time second-device commitment value received from the second device; and wherein: the proxy device is configured to enter a digest phase in response to a successful verification of the one-time first-device commitment value and of the one-time second-device commitment value in the commitment phase; the proxy device is configured, when in the digest phase, to calculate a one-time digest from i) the first-device data stored by the proxy device, ii) the second-device data stored by the proxy device, iii) the first-device secret-key information received from the first device, and iv) the second-device secret-key information received from the second device, and to send the one-time digest to the second device; and the second device is configured to authenticate the first device by using at least i) the first-device data stored by the second device, ii) the second-device data stored by the second device, iii) the first-device secret-key information received from the first device, and iv) the second-device secret-key information, to verify the one-time digest received from the proxy device.

10. The communication system of claim 9, wherein at least one of the first device, the second device, and the proxy device is a sensor or a sensor hub.

11. The communication system of claim 9, wherein the proxy device is further configured to send the one-time digest to the first device, and the first device is configured to authenticate the second device by using at least i) the first-device data stored by the first device, ii) the second-device data stored by the first device, iii) the first-device secret-key information, and iv) the second-device secret-key information received from the second device, to verify the one-time digest received from the proxy device.

12. The communication system of claim 9, wherein the proxy device stores proxy data and a proxy-device private key, and wherein the proxy device is configured, in a commitment phase, to use the proxy data and proxy-device secret-key information to generate a one-time proxy-device commitment value, the proxy-device secret-key information comprising, or being derived from, the proxy-device private key and a third random nonce.

13. The communication system of claim 9, wherein the second device stores the proxy data and the proxy-device private key, the proxy device being configured to send the one-time proxy device commitment value to the second device, and to communicate the proxy-device secret-key information to the second device, and wherein the second device is configured to use the proxy data stored in the second device, and the proxy-device secret key information received from the proxy device, to verify the one-time proxy-device commitment value received from the proxy device.

14. The communication system of claim 13, wherein: the proxy is configured to additionally use the proxy data and the proxy-device secret key information to calculate the one-time digest value; and the second device is configured to additionally use the proxy data stored by the second device, and the proxy-device secret-key information received from the proxy device, to verify the one-time digest received from the proxy, when authenticating the first device.

15. The communication system of claim 12, wherein the first device stores the proxy data and the proxy-device private key, the proxy device being configured to send the one-time proxy device commitment value to the first device, and to communicate the proxy-device secret-key information to the first device, and wherein the first device is configured to use the proxy data stored in the first device, and the proxy-device secret key information received from the proxy device, to verify the one-time proxy-device commitment value received from the proxy device.

16. The communication system of claim 15, wherein: the proxy is configured to additionally use the proxy data and the proxy-device secret key information to calculate the one-time digest value; and the first device is configured to additionally use the proxy data stored by the first device, and the proxy-device secret-key information received from the proxy device, to verify the one-time digest received from the proxy, when authenticating the second device.

17. The communication system of claim 9, wherein the first-device data comprises first identification data that identifies the first device, and the second-device data comprises second identification data that identifies the second device.

18. The communication system of claim 9, wherein the first device, second device, and proxy device comprise radios and are configured to communicate by radio.

19. The communication system of claim 9, wherein the first device, second device, and proxy device are configured to communicate over one or more wired links.

Description

BRIEF DESCRIPTION OF THE DRAWINGS

[0083] Certain preferred embodiments of the invention will now be described, by way of example only, with reference to the accompanying drawings, in which:

[0084] FIG. 1 is a schematic diagram showing two assets and a proxy, which are configured to participate in an authentication protocol embodying the invention;

[0085] FIG. 2 is a flow chart showing the main phases of an authentication protocol embodying the invention;

[0086] FIG. 3 is a flow chart providing a more-detailed view of the “Handshaking” phase of the authentication protocol as it is implemented during initial deployment of the assets;

[0087] FIG. 4a is a flow chart providing a more-detailed view of the first part of the “Handshaking” phase of the authentication protocol as it is implemented when authenticating the assets after the initial deployment of the assets;

[0088] FIG. 4b is a flow chart providing a more-detailed view of the second part of this after-deployment “Handshaking” phase of the authentication protocol;

[0089] FIG. 5 is a flow chart providing a more-detailed view of the “Commitment” phase of the authentication protocol;

[0090] FIG. 6 is a flow chart providing a more-detailed view of the “Checking” phase of the authentication protocol, in which the commitment values are checked;

[0091] FIG. 7 is a flow chart providing a more-detailed view of the “Final Digest” phase of the authentication protocol, in which a final digest value is generated and shared; and

[0092] FIG. 8 is a flow chart providing a more-detailed view of the final “Milestones” phase of the authentication protocol, in which it is checked that each asset has passed through each required milestone.

DETAILED DESCRIPTION

[0093] FIG. 1 shows components of a wireless sensor network comprising an asset A 100, an asset B 101, and a third asset, referred to as a proxy 102 or asset P, that are configured to take part in an authentication protocol embodying the invention. The network may contain many more assets than this. Each of these assets contains a respective memory 103, a clock 104, a radio 105 and a processor 106. The memories 103 may store software comprising instructions for executing on the respective processors 106 in order to carry out some or all of the steps described herein. Alternatively, the assets 100, 101, 102 may contain dedicated hardware, such as crypto-accelerators (not shown), for carrying out at least some of the steps. The assets 100, 101, 102 may contain batteries, user interfaces, sensors, etc. They communicate with each other by radio.

[0094] These assets can be, for example, Internet-of-Things sensors or sensor hubs. For example, asset A 100 could be a sensor located in a lamppost, asset B 101 could be a sensor located in a vehicle, and the proxy 102 could be a sensor embedded in the road, close to the lamppost. During the brief time window that the vehicle passes in radio proximity to both the lamppost and the road sensor, the vehicle sensor B may wish to authenticate with the lamppost sensor A before exchanging sensor data from the lamppost sensor A. The authentication is secured by additionally communicating with the road sensor 102, as described in more detail below. In some embodiments, one or both of the assets A and B 100, 101 could be gateway devices, interfacing between two different networks, such as a local-area network and the Internet.

[0095] FIG. 2 shows an overview of an authentication protocol which is an embodiment of the present invention. It may be implemented in the sensor network of FIG. 1, or another network.

[0096] The protocol begins with an asset (e.g., asset A 100), or group of assets, which will be referred to as Asset A, issuing an authentication signal to another asset (e.g., asset B 101), or group of assets, which will be referred to as Asset B. Upon receipt of this authentication signal, Asset B issues an authentication request to a third asset (e.g., proxy 102), referred to as a “Proxy” or Asset P. This proxy then issues a further request to both of the assets A and B, and the authentication proceeds once each asset successfully receives this request from the proxy. This all takes place at the “Request” step 2 of the flow chart of FIG. 2. It is shown in more detail in FIGS. 3 and 4.

[0097] A request is made each time authentication is required, and an asset's authentication ceases as soon as the particular communication, for which authentication was required, ceases. As a result, the authentication is “always off” other than when it is deliberately in use, so that there is no permanent authentication for any assets; in other words, authentication occurs on a need-only basis, thereby improving the security of the protocol.

[0098] The requests are all issued on a first communication band, referred to as Band 1, which could be an 802.15.x channel.

[0099] More generally, the protocol can be carried out with all communications being transmitted on a single communication band, Band 1. However, in a preferred embodiment, two different communication bands are used to transmit the data at different points during the protocol. These communication bands can be for example any kind of WiFi connection, Bluetooth, or wired connection—for example, Band 1 could be an 802.11.x wireless channel while Band 2 could be an 802.15.x wireless channel.

[0100] In order for Asset A to authenticate with Asset B and the proxy, this particular example embodiment requires that all the assets must have identical provisioning characteristics, meaning that they must all be permitted to communicate with all the same assets. The assets must have identical natural properties, NP, where these natural properties can comprise any combination of alphanumeric characters, real numbers, dates, times or group identities. Other embodiments may not have this requirement.

[0101] The next phase in the authentication protocol is referred to as “Handshaking”, shown at step 4 of FIG. 2. There are two alternative “Handshaking” phases. The first 4a, shown in detail in FIG. 3, only takes place during initial deployment of a group of assets, for example when the assets are all configured in the factory. The second, alternative “Handshaking” phase 4b takes place during any authentication which occurs “after deployment” (e.g., following initial deployment from the factory), for example when the sensors have been installed in other devices; this phase 4b is shown in detail in FIGS. 4a & 4b.

[0102] When Handshaking takes place during initial deployment of the assets as detailed in stage 4a of FIG. 3, each asset, or group of assets, compresses certain properties, encrypts these properties and shares them with the other assets. These properties can include a unique ID, “UID”, which is a concatenation of the asset's Hardware ID, Virtual ID, and Customer ID, as well as an “INFOx”, which is a set of data representing unique properties of asset x, plus a time stamp value based on an internal clock of the particular asset, and a “PSx” which is the provisional spec or permissions that the asset has (e.g., permissions Time On|Off, one-time duration of work, intervals of work, conditional, exception, Implied, is/is not, More/Less, At least, . . . ). The internal clocks of the sensors may be synchronised during an initial set-up phase and/or at intervals thereafter, using a known synchronisation method. The Hardware ID is a unique ID baked-in when the asset is being manufactured. The Virtual ID is a randomized SHA-3 hash value of the asset's namespace values created during the asset's first start. The Customer ID is the unique customer ID of the customer to whom the asset belongs, and is created during initial protocol deployment. Each asset then uses an AES key, which is a key pre-installed on all assets by the customer or manufacturer, to encrypt these properties. These compressed and encrypted properties are then shared with all assets participating in the authentication process over communication Band 1. Each asset then awaits confirmation of receipt of the properties by all the other assets, and resubmits these properties until either receiving this confirmation or until timeout. All of these shared properties are stored by every asset permanently in the memory 103 of each asset.

[0103] Each asset has, pre-set, values that include: Hardware ID, Model Name, Model ID, Serial Number, etc. When booted, each asset generates its Unique ID=Hardware_ID, Virtual_ID, Customer_ID.

[0104] Every asset, including the trusted proxy, should also have the following values defined, before the authentication begins: [0105] INFO data for participating in authentication (excluding a time stamp, which is added during the authentication process); [0106] provisional spec data for participating in authentication; [0107] a common AES-128 encryption key to start sharing encrypted data between assets; [0108] a Handshaking timeout; [0109] a Commitment exchange timeout; and [0110] a Secret Key exchange timeout.

[0111] When Handshaking takes place after initial deployment of the assets, as shown at stage 4b of FIGS. 4a & 4b, none of the asset's properties are shared directly, so as to improve the security of the protocol. Rather, each asset (including the proxy) generates a 20-bit nonce, a random number which is used only once, at stage 30. Each asset then generates a time stamp and writes this to its respective INFO array, at stage 31. Each asset then calculates a 20-bit SHA-3 hash value, PH (properties hash), from a concatenation of its own properties—UID, INFO, PS—at stage 32. Each asset then calculates a further SHA-3 hash value, NPH (nonced properties hash), from a concatenation of the nonce, from stage 30, and the property hash value, from stage 32, at stage 34. Each asset then submits both its NPH hash value and its nonce value to all other assets over Band 1, and keeps sharing these values until confirmation is received or until a timeout, as shown at stage 36 in FIG. 4b.

[0112] If, at any stage, an asset does not receive confirmation of receipt of details which are being transmitted to the other participating assets, and a timeout limit is reached, then the asset ceases to participate in the authentication session, as is indicated by a black circle symbol 16 in the flow charts. If it is the proxy that reaches such a state, the proxy will stop the entire authentication session (not just its own participation).

[0113] Upon receipt of the NPH and nonce values from other assets, each asset then uses the stored records it obtained during the deployment stage 4a to identify the properties of the participating assets by recalculating the received NPH values, as shown at step 38.

[0114] Completion of either of these alternative “Handshaking” steps 4a or 4b is recorded as a first “milestone” by each of these assets. Each asset must pass through five milestone steps in the authentication protocol, as shown in FIG. 2, as well as the final phase of the protocol, before an asset is granted an authenticated status. Assets therefore need to note (e.g., store a flag in memory) that they have passed through each of the five required milestones. An explanation of how this is checked is given later with reference to FIG. 8.

[0115] After “Handshaking”, the assets proceed to a “Commitment” phase 6, shown briefly in FIG. 2, and in more detail in FIG. 5. In this phase 6, each participating asset first generates a 204-bit nonce at step 40. Each asset then takes its own private key, which is a 20-bit key individual to each asset, created during operating-system boot of the asset, based on the asset's UID and never shared, and concatenates this private key with the nonce generated at step 40, to generate a one-time 224-bit secret key at step 42. Since this secret key includes a nonce, it is different during each authentication session and unique to each session.

[0116] At step 44 each asset then calculates a respective commitment value, C.sub.x. The commitment value is calculated as a SHA-3 hash function,

C.sub.x=hash s.sub.x(UID.sub.x,INFO.sub.x,PS.sub.x)

[0117] where S.sub.x is the secret key of asset x, generated at step 42, UID.sub.x is the concatenation of the Hardware ID, Virtual ID and Customer ID of asset X, and INFOx is a set of data describing asset X (i.e., unique properties of asset X). This INFOx value includes a time-period-stamp so that this INFO value is specific to a particular authentication session and is time bound. The time stamp is based on the internal clock of each asset, and these clocks are synchronised during the initial setup process. PSx is the provisional spec, or permissions, of asset X. These commitment values are therefore different in every authentication session and unique to each session. Since unique keys are generated between assets in each authentication attempt, there are no permanent keys or certificates that could be hacked by an attacker.

[0118] Each asset then encrypts its own commitment value using the common AES key and submits its encrypted commitment value to all other participating assets over the second communication channel, Band 2, at step 46. (Use of a second band may provide additional security; however, in some embodiments only one band, Band 1, is used instead.) Each asset then decrypts and stores the commitment values received from all other participating assets. Each asset continues to re-submit the encrypted commitment values until confirmation is received, or until a Commitment exchange timeout is reached. Once confirmation is received by an asset, for example asset A, that all other assets have received the commitment value sent by asset A, asset A is deemed to have reached the second milestone, M2.

[0119] Each asset then encrypts its one-time Secret Key using the AES key stored by all assets, and submits this Secret Key to all other participating assets over communication Band 1, as shown at stage 48 of FIG. 5, and stage 8 of FIG. 2. As with the commitment value, each asset re-submits this Secret Key value until confirmation is received from all other assets of receipt of the Secret Key, or until a timeout limit is reached, in which case the particular asset which has reached the timeout limit ceases to participate in the authentication protocol, as shown at symbol 16. Once confirmation is received from all other assets of receipt of an asset's Secret Key value, that asset is deemed to have reached the third milestone, M3. Each asset stores the received Secret Keys of the other assets for a particular authentication session for the duration of that particular session.

[0120] The next phase in the authentication protocol is for each asset to check the commitment values submitted by all other assets, at the “Checking commitment value” phase, shown in stage 10 of FIG. 2, and in more detail in FIG. 6. At this phase, each asset uses its own records of the properties of other authenticating assets, which were stored during the initial pre-deployment Handshaking stage 4a, and which were identified during Handshaking stage 4b, together with the secret key values stored after the previous phase, to calculate expected values for the commitment values of each other participating asset, as shown at stage 50.

[0121] For example, asset A has determined at stage 4b which stored UID, PS and INFO values correspond to asset B. Asset A then calculates the commitment value hash function given above, using these values (including, in the INFO value, the current time stamp according to the internal clock of Asset A), and using the Secret Key for asset B which was previously submitted to asset A on communication Band 1.

[0122] Each asset then checks whether there is a match between the commitment values initially submitted by each of the other assets and the recalculated commitment values, at stage 52. If they do not match, the asset ceases to participate in the authentication process. If they do match for a particular asset, e.g. asset A, this asset is deemed to have reached the fourth milestone of the authentication process, M4. If they match, each asset then submits these recalculated commitment values to the proxy 102 at stage 54, and the proxy checks whether there is a match between the commitment values initially submitted by the other assets (e.g., asset A and asset B) and the recalculated commitment values received from these other assets. If the values do not match, then the asset for which the commitment values do not match ceases to participate in the authentication process. In some embodiments, the fourth milestone, M4, for each asset, is not reached until the proxy has carried out this further check.

[0123] The process then proceeds to the “Final Digest” phase, shown at stage 12 of FIG. 2, and in more detail in FIG. 7. At this phase the proxy then generates an OMEGA value, also referred to as a Final Digest value, based on the stored record it has of the properties of the other participating assets, as shown at stage 60. Specifically, this OMEGA value is given by

Ω=hash.sub.k(INFOS),

where

k=S.sub.A⊕S.sub.B−S.sub.P

where Sx is the secret key of asset x, and where ⊕ represents bitwise XOR.

[0124] INFOS is a concatenation of the information for every asset participating in the authentication protocol, sorted in alphabetic order before the concatenation: (UID.sub.A, INFO.sub.A, PS.sub.A).(UID.sub.B, INFO.sub.B, PS.sub.B).(UID.sub.P, INFO.sub.P, PS.sub.P).

[0125] Although the authentication protocol has been exemplified for two assets and a proxy asset, it will be appreciated that it can be extended to any number of assets. In this case, INFOS will be the concatenation of the information for all of the participating assets, and k will be the bitwise XOR of the secret keys of all the participating assets.

[0126] This OMEGA value is then sent from the proxy to every asset over communication Band 2, at stage 62. Each asset then re-calculates the OMEGA value using its own stored data about all the other authenticating assets, at stage 62, and then indicates whether these values match. Once it is confirmed by an asset (e.g., asset A) that its recalculated OMEGA value matches the OMEGA value submitted by the proxy, that particular asset is deemed to have reached the fifth milestone, M5. Each asset that recalculate and verifies this OMEGA value thereby determines that this value has been provided by a genuine proxy which participated in the authentication session from the beginning.

[0127] The role of the proxy is to act as an independent third body possessing a certain level of trust (because it has been authenticated before and is authorized to play role of proxy for the authentication of specified types of devices, using specific bands, etc.) to ensure independent facilitation of authentication session, validation of commitments made by assets A, B and other participating assets (if any) and to broadcast the final digest value Ω among authenticating assets that cannot be changed by the assets. The value Ω is, however, received and re-calculated by the assets to eliminate the possibility of spoofing the proxy.

[0128] The final phase in the authentication protocol is then to check that each asset has passed through all of the required milestones, as shown in stage 14 of FIG. 2, and in more detail in FIG. 8. This phase ensures that a malicious asset cannot “sneak in” during an authentication protocol.

[0129] In order to check that a particular asset, e.g. asset A, went through all of the five required milestones, a step 70 is performed in which the asset X generates a 224-bit length string:

M=hash(H.sub.P,C.sub.P,C.sub.X,Ω)

where H.sub.P is the compressed AES encrypted properties of the proxy, C.sub.P is the proxy's commitment value, C.sub.X is the commitment value of the asset itself, and Ω is the final digest value, as described above with reference to FIG. 6. Each of these properties is calculated or received by the asset X prior to a respective one of the required milestones, and therefore corresponds to a particular milestone. Therefore, correct generation of this value confirms that a particular asset has passed through all of the milestones.

[0130] Although not shown explicitly in FIG. 8, within the checking step 70, this generated value is then sent to the proxy, which recalculates the value M using its own records of the required values. If these values match then the proxy generates a 224-but Unique Authentication Number (UAN), where

UAN=hash(M)

and submits this UAN number to all of the assets participating in the authentication protocol. After receipt of this number, each asset (e.g., asset A) receives an “authenticated” status with the proxy and with all of the other participating assets, shown by the “Yes” branches in FIG. 8, which lead to respective “Authenticated” boxes. The same process is applied to every other asset participating in the authentication process. These UAN numbers can be recorded and stored if required, for example it can be recorded into the blockchain.

[0131] After the assets are authenticated, the provisioning of each asset may allow assets with particular permissions to communicate specific types of data to specific assets over specific ports and/or to access specific sources of data. For example, if PSx data is provisioned, successful initial protocol deployment automatically authorizes participating assets to complete specific actions defined in PSx. Every consequent successful authentication run for the assets (using the after-deployment handshaking) automatically authorizes the assets to complete the same action with no necessity to provision the authorization for the assets again to execute the same actions.

[0132] Although Asset A has been used as an example in places within this description, it should be understood that the description applies likewise to Asset B, and to the case where one or both of these assets actually comprises a group of assets, and to a situation in which there are three or more assets, in addition to the proxy, that are mutually authenticating. The protocol allows authentication simultaneously of an arbitrary number of assets.

[0133] In the above described example two communication bands, Band 1 and Band 2, are used, with Band 2 being used for sharing the commitment values and the final OMEGA value, and Band 1 being used for all other data exchange during the authentication session. In the event that only one communication band is available the authentication protocol can proceed with all communications being transmitted on a single band, either of Band 1 or Band 2.

[0134] The authentication protocol embodiment described above is believed to provide a method of point-to-point quantum-resistant authentication that allows any two digital assets or groups of assets to securely authenticate with one another without the need for third party certificates or the public key infrastructure. Further, no Internet connection, centralised means of communication, or third party database is necessarily required by either asset or groups of assets to complete the authentication process, thereby allowing decentralised real-time, ‘de novo’, always-off, as-needed, authentication. After the initial deployment “Handshaking” phase of FIG. 3, all data values being exchanged between participating assets during the run of an authentication session are randomized, one-time, one-way, never-the-same (within SHA-3 capability) values, meaning that the proof is zero-knowledge, as each asset proves its identity to the other participating assets without explicitly revealing any identity data via a communication band. This brings quantum resistance of the protocol and leaves no reason to replay or to eavesdrop. This offers an advantage over using, for example, merely relying on the shared AES key for authentication, which is used multiple times and is a symmetric block cipher. If the AES key becomes known to an adversary the authentication process is compromised. By contrast, in the above-described authentication protocol embodiment there is nothing to compromise, since commitment values and secret keys which are shared between assets are all one-time values which are specific and unique for every session.

[0135] In order to further explain the advantages of the above described authentication protocol embodiment, there follow below some examples of possible malicious attacks which might be deployed against the protocol. For each possible attack, an explanation is provided of how these attacks are believed to be countered by the protocol. These statements relate only to the example embodiments disclosed with reference to the accompanying drawings; they are not necessarily all equally applicable to every embodiment of the invention.

Eavesdropping Attack

[0136] An attacker taps the information that goes on the wire or wireless and uses it for future purpose. It is a kind of replay attack. It may be network eavesdropping or offline eavesdropping.

[0137] During the run of this protocol there is no reason to eavesdrop since all exchanged data values during after-deployment-authentication session are random one-time one-way (non-reversible) values. Since the Asset-attacker did not participate in an initial protocol deployment session, which, in this embodiment, is mandatory for the assets running the protocol for the first time, it has no initial knowledge about real properties (UID, INFO, PS) of Asset A (as well as, Proxy and other assets in the group), Consequently, an Asset-attacker will not be able to re-calculate the correct commitment values of other the participating assets to prove a match at the CHECKING COMMITMENT VALUE phase of the protocol, shown in FIG. 6.

[0138] An asset-attacker must submit the recalculated value of the commitments made by other assets (not just a logical TRUE or FALSE signal indicating a match) and the proxy checks if there is a match of the other asset's commitment value provided originally by the other assets and the one provided by Asset-attacker on behalf of eavesdropped asset. If the proxy does not find a match, the asset, which recalculated the non-matching commitment value (i.e. Asset-attacker), will be denied and reported.

[0139] The data eavesdropped in a current session will not be useful for the next session if replayed, because at the Handshaking phase, shown in FIGS. 4a & 4b, Asset-attacker will fail to derive real properties of other participating assets and Proxy from received hash values because of it lacks initial knowledge about their real properties (UID, INFO, PS). This will lead to the Asset-Attacker failing to re-calculate the correct commitment values for the other participating assets and Proxy at the CHECKING COMMITMENT VALUES phase, shown in FIG. 6. Again, if the proxy does not prove a match, the asset, which recalculated the non-matching commitment values (i.e. Asset-attacker), will be denied and reported.

[0140] Although during initial deployment the assets share AES encrypted values of UID, INFO, PS, during the Handshaking phase of FIG. 3, this initial deployment takes place only once and, again, this shared data will be worthless in any future after-deployment authentication sessions.

Man-in-the-Middle Attack

[0141] MITM is a kind of eavesdropper attack. An attacker comes in between two assets, or asset and proxy and all the communication between them goes only through the attacker. So he impersonates both the parties to one another and may copy, alter or delete a portion of the data traffic between them i.e. attack on mutual authentication. It may be a passive attack or active attack.

[0142] To prevent MITM attack the assets and proxy are being mutually authenticated during one-time initial protocol deployment by sharing their AES-encrypted real properties (UID, INFO, PS) between each other. Assuming the MITM impersonates an authenticated asset, since the MITM did not go through initial protocol deployment phase and it has no initial knowledge about real properties of already authenticated assets and proxy. The MITM will fail to recalculate correct commitment values for authenticated assets and Proxy at the CHECKING COMMITMENT VALUES phase of FIG. 6, and will not be authenticated, i.e. not trusted, to perform specific actions on behalf of any asset it may want to impersonate.

Forged Asset

[0143] In this attack the asset-attacker acts as a copy (clone) of a legitimate asset (which was burnt, for example) and the attacker attempts to participate in an authentication session with other assets by issuing an authentication request to the proxy as a legitimate asset would do after a disconnect had occurred for some reason.

[0144] Even knowing the AES encryption key, the forged asset would fail to successfully pass the CHEKING COMMITMENT VALUE phase of FIG. 6. The after-deployment protocol data exchange is a zero-knowledge proof, i.e. an asset and/or proxy shares only hashed values of its identity data (UID, INFO, PS) to other participating assets without explicit revealing its real identity data to the other assets.

[0145] Even if a forged asset were a total clone of a genuine asset and therefore knew INFO and PS data, it would be denied and reported at the CHEKING COMMITMENT VALUE phase of FIG. 6 because it would have a NULL or different randomized unique ID UID=HID.VID.CID, which is used to calculate the commitment and final digest values, as explained above.

[0146] If an asset-attacker was somehow able to sneak-in to the group of assets during the very first one-time protocol initial deployment phase, during which the assets share their properties, this would fail, because the illegitimate asset would need to have a fresh AES encryption key installed. This AES key is pre-installed only on legitimate assets before they go through the initial deployment version of the above described protocol.

Forged Proxy

[0147] In this attack an attacker acts as a legitimate proxy that facilitates an authentication process for other assets and responds to legitimate asset's challenges (requests) to authenticate.

[0148] Since the protocol implements a mutual authentication approach, all assets check the proxy's commitments too. Due to this feature the forged proxy case is similar to the forged asset case discussed above. The difference is simply when the proxy will be denied and reported. On the CHECKING COMMITMENT VALUE phase of FIG. 6 the proxy checks and decides if an asset will proceed to next phase of the authentication process, genuine authenticating assets will not recognise a forged proxy at this phase. However, at the FINAL DIGEST phase of FIG. 7, after the assets re-calculate the final digest value which was announced by the forged proxy and compare the digest value to what they calculated based on their own knowledge of genuine proxy properties, the genuine assets will detect a not-match, report the proxy as not being legitimate, and remove themselves from the authentication session.

[0149] If a forged proxy were to somehow sneak-in to a group of assets authenticating during the very first one-time initial deployment protocol, the forged proxy would fail this too, because the proxy must have a fresh AES encryption key installed to decrypt the properties of other assets and get to know their UID, INFO and PS. The AES key is pre-installed only on legitimate assets before they go through the initial deployment protocol.

Replay Attack (in the Next after-Deployment Session)

[0150] In this attack, the attacker tries to replay the authentication session values (eavesdropped in earlier session) of a specific asset in the next session trying to make the proxy and other assets think that the attacker is one of the legitimate assets in order to be authenticated.

[0151] Since the attacker did not go through the initial protocol deployment session, shown in FIG. 3, it has no initial knowledge about the real properties (UID, INFO, PS) of Asset A (as well as the Proxy and the other assets in the group) and, as a result, cannot resolve the other asset properties based on received hashed data values only. Consequently, the attacker will not be able to re-calculate the correct commitment values of the proxy and other assets to prove a match, when the proxy checks for this match. Furthermore, the INFO property of all assets includes also a time-period-stamp. So, at different (time+x seconds period) the INFO property value will be different and, as a result, the calculated commitment values and final digest values will be different for all each other sessions. Due to this feature replay attacks in future authentication sessions can be effectively prevented.

[0152] Suppose, at the CHECKING COMMITMENT VALUE phase of the protocol, in FIG. 6, where the genuine asset must submit its calculated commitment value, the attacker instead of calculating a fresh commitment simply submits an earlier (in previous session) eavesdropped commitment value of attacked genuine asset (e.g. Asset B). The eavesdropped Asset B's commitment value will appear to be different from Asset B's current commitment value which is recalculated by the proxy based on its initial knowledge about real properties (UID, INFO, PS) of Asset B and the current time-period-stamp value. As a result, Asset-B-Eve will be denied and reported by the proxy.

Replay Attack (within Current after-Deployment Session)

[0153] In this attack, the attacker tries to replay the authentication session values of targeted asset in a current session to make the proxy and other assets think that the attacker is a legitimate asset in order to be authenticated.

[0154] Since the attacker did not go through the initial protocol deployment session of FIG. 3, it has no initial knowledge about real properties (UID, INFO, PS) of Asset A (as well as the Proxy and the other assets in the group) and, as a result, cannot resolve the other asset properties based on received hashed data values. Consequently, the attacker will not be able to calculate correctly its “own” commitment value or re-calculate correct current commitment values for the proxy and other assets to prove a match when the proxy checks for this match.

[0155] Every new randomized hash value and nonce being transmitted during the after-deployment handshaking phase (FIGS. 4a & 4b) becomes invalid immediately (from asset-recipient's standpoint) after they have been received by an asset-recipient. An attacker needs at least a one-time data transmission event to eavesdrop the data. If the attacker wants to transmit eavesdropped data in the same session, these same data will be rejected by recipients, since the recipients have already received the one-time values from the genuine asset B which they then receive from the eavesdropping Asset B. In this situation the attacker will be denied and reported.

Injection Attack

[0156] This attack can be introduced after passing the replay attack. In this attack, the attacker attempts to inject false data into the group of authenticated assets. It must be authenticated to do so.

[0157] Since the above-described protocol embodiment prevents replay attacks, the injection attack is also preventable.

Session Hijacking Attack

[0158] In this attack, the attacker attempts to take control of the authentication session by substituting the proxy or sneaking-in in the middle of the session as a proxy.

[0159] Since the protocol prevents the possibility of authentication using a forged proxy (see above) and at the end of every session there is final CHECKING MILESTONES phase (FIG. 8) which eliminates the possibility for any asset(s) being authenticated if the asset did not go through all the required milestones of the authentication protocol, it is therefore not possible for an attacker to successfully complete an authentication session by hijacking the session.

Brute Force

[0160] A brute force attack is a trial-and-error method used to obtain data values exchanged by assets during an authentication session. In a brute force attack, automated software is used to generate a large number of consecutive guesses as to the value of the desired data.

[0161] In this protocol embodiment, asset properties are hashed using the randomized one-way SHA-3 hash function and reverse-engineering of this property data from the hash values is impossible with extremely high probability. Furthermore, the session duration is very short (usually less 0.01 sec, depending on the quantity of the authenticating assets); the SHA-3 hashed asset commitment values are different for every participating asset in the session and the SHA-3 hashed final digest values are different in every new authentication session. Therefore, guessing the correct combination of all exchanged authentication values during such a very short session is practically impossible and infeasible, thus minimising the risk of a brute force attack.

[0162] It will be appreciated by those skilled in the art that the invention has been illustrated by describing one or more specific embodiments thereof, but is not limited to these embodiments; many variations and modifications are possible, within the scope of the accompanying claims.