CROSS-REFERENCE TO RELATED APPLICATIONS

The present application is a continuation-in-part (C-I-P) of U.S. Patent Application Serial No. 15/796,577 to Kuang, filed on October 27, 2017; benefit is claimed under 35 U.S.C. 120. The present application is also a C-I-P of International PCT Application Serial No. PCT/CA2018/051339 to Kuang et al., filed on October 23, 2018; benefit is claimed under 35 U.S.C. 120. The content of both of the foregoing applications is hereby incorporated by reference herein.

FIELD

The present invention relates in general to data communications and, in particular, to data communications security.

BACKGROUND

The security of digital communications between communicating parties is often judged according to the strength of the key and algorithm used to encode or encrypt the data being transmitted. However, a security risk may arise in the process of making sure that each party knows what key to use. This is especially true when keys are distributed over a channel that has been compromised by a malicious party. Meanwhile, the communicating parties may be under the illusion that the link is secure, which exacerbates the problem.

As such, improved ways of enhancing the security of digital communications between parties would be welcomed by the industry. SUMMARY

In accordance with a broad aspect, there is provided a computer-implemented method comprising: generating a token associated with a first network node;

storing the token in association with an identifier;

receiving a request from a second network node, the request specifying the identifier;

retrieving the token based on the identifier; and

sending the token to the second network node in response to the request.

In accordance with a broad aspect, there is provided a server comprising a memory and a processor, the memory storing computer-readable instructions, the processor configured to read and execute the computer-readable instructions to carry out a method that comprises:

generating a token associated with a first network node;

storing the token in association with an identifier;

receiving a request from a second network node, the request specifying the identifier;

retrieving the token based on the identifier; and

sending the token to the second network node in response to the request.

In accordance with a broad aspect, there is provided a non-transitory computer-readable medium comprising computer-readable instructions which, when read by a processor, cause the processor to implement a method that comprises:

generating a token associated with a first network node;

storing the token in association with an identifier;

receiving a request from a second network node, the request specifying the identifier;

retrieving the token based on the identifier; and

sending the token to the second network node in response to the request.

In accordance with a broad aspect, there is provided a computer-implemented method for a recipient to validate a message received from a sender, the message including a first part and a second part, the method comprising: - receiving a token from a trust authority;

- obtaining a first data element by joint processing of the first part of the message and the token;

- obtaining a second data element by joint processing of the second part of the message using a key associated with the sender; and

- validating the message by comparing the first and second data elements.

In accordance with a broad aspect, there is provided a server comprising a memory and a processor, the memory storing computer-readable instructions, the processor configured to read and execute the computer-readable instructions to carry out a method that comprises:

- receiving a token from a trust authority;

- obtaining a first data element by joint processing of the first part of the message and the token;

- obtaining a second data element by joint processing of the second part of the message using a key associated with the sender; and

- validating the message by comparing the first and second data elements.

In accordance with a broad aspect, there is provided a non-transitory computer-readable medium comprising computer-readable instructions which, when read by a processor, cause the processor to implement a method that comprises:

- receiving a token from a trust authority;

- obtaining a first data element by joint processing of the first part of the message and the token;

- obtaining a second data element by joint processing of the second part of the message using a key associated with the sender; and

- validating the message by comparing the first and second data elements.

In accordance with a broad aspect, there is provided a computer-implemented method for transmitting a message to a recipient, comprising:

- generating a token from a shared state known to a trust authority;

- generating a signature from message data and the token;

- generating a message from the message data and the signature;

- sending the signature to the trust authority; and

- sending the message to the recipient. In accordance with a broad aspect, there is provided a computing device comprising a memory and a processor, the memory storing computer-readable instructions, the processor configured to read and execute the computer-readable instructions to carry out a method for transmitting a message to a recipient, the method comprising:

- generating a token from a shared state known to a trust authority;

- generating a signature from message data and the token;

- generating a message from the message data and the signature;

- sending the signature to the trust authority; and

- sending the message to the recipient.

In accordance with a broad aspect, there is provided a non-transitory computer-readable medium comprising computer-readable instructions which, when read by a processor, cause the processor to implement a method for transmitting a message to a recipient, the method comprising:

- generating a token from a shared state known to a trust authority;

- generating a signature from message data and the token;

- generating a message from the message data and the signature;

- sending the signature to the trust authority; and

- sending the message to the recipient.

In accordance with a broad aspect, there is provided a system comprising a sender node and a trust authority, wherein:

the trust authority is configured to:

o generate a token from a shared state associated with the sender node;

o store the token in association with an identifier;

the sender node is configured to

o generate said token;

o generate a signature from message data and the token;

o generate a message from the message data and the signature; o send the signature to the trust authority; and

o send the message to the recipient node; and

the trust authority is further configured to:

o receive a request from the recipient node, the request specifying the identifier; o retrieve the token based on the identifier; and

o send the token to the recipient node in response to the request.

In accordance with a broad aspect, there is provided a computer-implemented method, comprising:

maintaining a first token for a first network node and a second token for a second network node;

generating a shared token, wherein the shared token is configured such that the second token is recoverable by processing the shared token and the first token; and sending the shared token to the first network node, thereby to enable the first network node to recover the second token from the shared token and a local version of the first token.

In accordance with a broad aspect, there is provided a server comprising a memory and a processor, the memory storing computer-readable instructions, the processor configured to read and execute the computer-readable instructions to carry out a method that comprises:

maintaining a first token for a first network node and a second token for a second network node;

generating a shared token, wherein the shared token is configured such that the second token is recoverable by processing the shared token and the first token; and sending the shared token to the first network node, thereby to enable the first network node to recover the second token from the shared token and a local version of the first token.

In accordance with a broad aspect, there is provided a non-transitory computer-readable medium comprising computer-readable instructions which, when read by a processor, cause the processor to implement a method that comprises:

maintaining a first token for a first network node and a second token for a second network node;

generating a shared token, wherein the shared token is configured such that the second token is recoverable by processing the shared token and the first token; and sending the shared token to the first network node, thereby to enable the first network node to recover the second token from the shared token and a local version of the first token. In accordance with a broad aspect, there is provided a computer-implemented method carried out by a first network node, the method comprising:

producing a first token that is known to a trust authority;

receiving a shared token from the trust authority, wherein the trust authority has knowledge of a second token that is known to a second network node; producing the second token from the shared token and the first token; and using the second token to communicate with the second network node to the exclusion of the trust authority.

In accordance with a broad aspect, there is provided a network node comprising a memory and a processor, the memory storing computer-readable instructions, the processor configured to read and execute the computer-readable instructions to carry out a method that comprises:

producing a first token that is known to a trust authority;

receiving a shared token from the trust authority, wherein the trust authority has knowledge of a second token that is known to a second network node; producing the second token from the shared token and the first token; and using the second token to communicate with the second network node to the exclusion of the trust authority.

In accordance with a broad aspect, there is provided a non-transitory computer-readable medium comprising computer-readable instructions which, when read by a processor of a network node, cause the processor to implement a method that comprises:

producing a first token that is known to a trust authority;

receiving a shared token from the trust authority, wherein the trust authority has knowledge of a second token that is known to a second network node; producing the second token from the shared token and the first token; and using the second token to communicate with the second network node to the exclusion of the trust authority. BRIEF DESCRIPTION OF THE DRAWINGS

With reference to the accompanying drawings, which are for illustrative purposes and are not intended to be limitative:

Fig. 1 is a block diagram illustrating a network architecture including a plurality of communication devices communicating over a data network.

Fig. 2 is a block diagram illustrating a possible internal structural configuration of one of the communication devices in the network architecture of Fig. 1.

Fig. 3 is a block diagram illustrating processes implemented by a node and by a trust authority, as well as inter-process communication;

Fig. 4A is a block diagram similar to that of Fig. 1, but in which each of the communication devices is designated as either a node or a trust authority.

Figs. 4B and 4C are block diagrams similar to that of Fig. 4A, but illustrating different arrangements of trust groups.

Fig. 5 shows an entropy history table held in a particular one of the nodes and an analogous entropy history table held in a trust authority associated with the particular node;

Fig. 6 is a block diagram illustrating a message exchange between the particular node and the particular trust authority;

Fig. 7 is a block diagram illustrating a network architecture in which a node referred to as Alice interacts with a witness in the course of generating a witnessed message to be communicated to a node referred to as Bob;

Fig. 8 is a block diagram illustrating generation and transmission of the witnessed message by Alice;

Fig. 9 is a block diagram illustrating validation of a received message by Bob;

Fig. 10 is a block diagram illustrating generation and publication of a witnessed blockchain transaction by Alice; Figs. 11A-11C are block diagrams illustrating session key establishment, in accordance with a non-limiting embodiment.

Fig. 12 is a block diagram illustrating secure web navigation, in accordance with a non-limiting embodiment.

Fig. 13 is a message flow diagram illustrating synchronization of an entropy state update, in accordance with a non-limiting embodiment.

Fig. 14 is a message flow diagram illustrating synchronization of generation of an initial entropy state, in accordance with a non-limiting embodiment.

Fig. 15 is a message flow diagram illustrating synchronization of generation of an initial entropy state, in accordance with another non-limiting embodiment.

Fig. 16 is a conceptual diagram illustrating implementation of an entropy plane, in accordance with non-limiting embodiments.

DETAILED DESCRIPTION

With reference to Fig. 1, there is shown a network architecture 100 that supports various embodiments disclosed herein. Specifically, the network architecture 100 comprises a plurality of communication devices 110 communicating over a data network 120, a non-limiting example of which is the internet. In other embodiments, the data network 120 may be any other public or private data network.

Fig. 2 shows a possible internal structural configuration of one of the communication devices 110, in accordance with a non-limiting embodiment. The communication device 110 includes a processing entity 212 connected to a memory 214 over a bus 222. Examples of the processing entity 212 may include electronic components such as a computer processor comprising a microchip or application-specific integrated circuitry, or a quantum computer. The memory 214 may be implemented in a variety of ways, such as a magnetic disk or solid state memory, and may include flash memory, SRAM, DRAM, phase-change memory and the like. The memory 214 stores computer-readable instructions, respective subsets of which encode an operating system and a set of processes. The processing entity 212 is configured to execute the computer- readable instructions in the memory 214. In doing so, the processing entity 212 of the communication device 110 causes the communication device 110 to implement the aforementioned operating system and set of processes. A user input/output (I/O) 218, connected to the processing entity 212 over the bus 222, enables the processing entity 212 to communicate externally with a user with the aid of peripherals such as a screen/touchscreen, keyboard/mouse, USB port, etc. A network interface 220, also connected to the processing entity 212 over the bus 222, enables the processing entity 212 to communicate externally over the data network 120 and may include a network interface device (e.g., to support Ethernet communications of various speeds, for example) and/or a wireless transceiver (e.g., to support NFC, WiFi, Ethernet or cellular / GSM / LTE communications, for example). Connection to the data network 120 may be established by a link 224 connected to the network interface 220.

As described above, in executing the computer-readable instructions in the memory 214, the processing entity 212 implements an operating system and a set of processes. Exactly which processes are implemented depends on the type or functionality of the communication device 110. In this regard, Fig. 3 conceptually shows processes implemented by a type of communication device referred to as a communication node (or simply a“node”) and denoted by the reference numeral 310. The processes implemented by the node 310 include, among others, a “node-side entropy state management process” 320 and a“data communication process” 330. Fig. 3B conceptually shows processes implemented by a type of communication device referred to as a“trust authority” (TA) and denoted by the reference numeral 340. The processes implemented by the trust authority 340 include, among others, a “TA-side entropy state management process” 350.

Generally speaking, the data communication process 330 of the node 310 communicates with analogous data communication processes of other nodes to implement a“data plane”. Also, the node-side entropy state management process of the node 310 communicates with the TA-side entropy state management process of the trust authority 340 to implement an“entropy plane”. In addition, although not shown, the entropy plane extends to communication between the TA-side entropy state management process of the trust authority 340 and the node-side entropy state management process of other nodes. Finally, the node-side entropy state management process and the data communication process 330 of the node 310 communicate with one another within the node.

Certain functional differences between a“node” and a“trust authority” may become apparent from the following description. In this regard, with reference to Fig. 4A, there is shown the network architecture 100 of Fig. 1, but where each of the various communication devices 110 is specified to be of a certain“type” that is either a node (in which case the reference numeral for that communication device is 310 followed by a letter) or a trust authority (in which case the reference numeral for that communication device is 340 followed by a letter).

So-called“trust groups” are defined in the network architecture 100 between individual trust authorities and corresponding subsets of nodes. In the specific non-limiting example illustrated in Fig. 4B, a first trust group 410A includes a first trust authority 340A and a first subset of nodes (in this case comprising nodes 310A, 310B and 310C). Other trust groups 410B, 410C are established between other ones of the trust authorities and corresponding other subsets of the nodes. For example, a second trust group 410B includes a second trust authority 340B and nodes 310D, 310E and 310F, whereas a third trust group 410C includes a third trust authority 340C and nodes 310G, 31 OH, 3101, 310J, 31 OK and 310L. There may also be overlap in the sense that a given node may belong to more than one trust group (i.e., such a node may be associated with more than one trust authority).

It should be appreciated that it is not required that a trust authority directly communicate with the nodes in its trust group - it may communicate with one or more nodes in its trust group through another trust authority as a proxy. It should also be appreciated that in some cases, and although not shown in Fig. 4B, a communication device may fulfill the role of both a node (associated with a first trust group) and a trust authority (for a second trust group).

A given node may establish a data plane communication channel with another node over the data network 120. This may be achieved through the data communication process 330 respectively implemented by each of the two nodes. Security of the data plane communication channel may be enhanced in the case where both nodes modify their data as a function of a so-called“entropy state” of at least one of the two nodes. In the simplest case, the two nodes capable of enhanced security communication are in the same trust group (i.e., are associated with the same trust authority). However, nodes within different trust groups can also establish secure connections by TA“bridging”. For example, Figure 4C illustrates a bridge 490 between trust authority 340B (associated with trust group 410B) and trust authority 340C (associated with trust group 410C). In this case, any two nodes within trust groups 410B and 410C can establish a secure connection. TA bridging greatly enhances the scalability of the platform, as nodes that subscribe to a trust group associated with one trust authority can still establish secure data plane connections with nodes that subscribe to a trust group associated with a different trust authority. TA bridging essentially provides a pre-authorized trust channel between trust groups. If each trust group is managed by a different“trust provider”, then TA bridging acts as a“glue” between trust providers to enable end-to-end trust between a pair of nodes in different trust groups. A certificate-based mechanism may be implemented for allowing two trust providers to pre- authorize establishment of a TA bridge.

The“entropy state” for each node associated with a particular trust authority is an element of information known both to the node itself and to the particular trust authority. The entropy state for each node may be dynamic, and changes in the entropy state are synchronized by entropy- plane interaction between the node-side entropy state management process (implemented by the node) and the TA-side entropy state management process (implemented by the trust authority for the trust group to which the node belongs). Of course, where a given node subscribes to multiple trust groups managed by respective trust authorities, there will be multiple entropy states for that node, one for each trust authority, and each entropy state will be independently synchronized by entropy -plane interaction with the corresponding trust authority

By way of non-limiting example, and with reference to Fig. 5, changes in the entropy state for a particular one of the nodes, in this case node 310A, can be recorded in an“entropy history table” 510, which can be held in the memory 214 of node 310A. More specifically, the entropy history table 510 includes a plurality of“entropy records” 520. Each entropy record 520 includes a plurality of entries, including a time indicator entry (e.g., time stamp or time frame or sequence number), an entropy state entry (under the“QE” column) and a hash entry. Each entropy record 520 is thus associated with a time frame, making it possible to readily access a previous entropy state if the corresponding time indicator is provided. The hash is produced by a one-way function that takes into account various information elements, such as the entropy state and an ID of trust authority 340A. It should be noted that the ID of trust authority 340A may also be included in an APP ID entry of the entropy record 520.

A virtually identical entropy history table 530A is stored in the memory 214 of trust authority 340A. Here, the APP ID entry of each entropy record of the entropy history table 530A is populated by an ID of node 310A. As was the case with node 310A, trust authority 340A can readily access a previous entropy state if the corresponding time indicator is provided desired. The memory 214 of trust authority 340A stores similar entropy history tables 530B, 530C for the other nodes belonging to trust group 410A associated with trust authority 340A. Together, the entropy history tables 530A, 530B, 530C can be amalgamated into a larger entropy history super-table (not shown).

In case node 310A also belongs to a second trust group managed by a second trust authority, a similar entropy history table will be stored in both the member 214 of node 310A and the memory of the second trust authority.

The entropy state for a given node is updated by locally generating an updated entropy state both at the node (e.g., nodes 310A, 310B, 310C) and at the corresponding trust authority (e.g., trust authority 340A). A certain amount of synchronization is needed. This synchronization can be initiated or managed by the corresponding trust authority or by the node.

By way of non-limiting example, and with reference to Fig. 6, the TA-side entropy state management process 350 of trust authority 340A may carry out a message exchange 610 with the node-side entropy state management process 320 of node 310A in order to generate an updated entropy state both at node 310A (where it is stored in a new record 520 of entropy history table 510) and at trust authority 340A (where it is stored in a new record of entropy history table 530A). It should be noted that synchronization of entropy state updates is done without the updated entropy state itself being communicated between trust authority 340A and node 310A over the data network 120. Certain details regarding the generation of an updated entropy state will be provided later on in this document.

In the event that two one of the nodes, say node 310A (hereinafter referred to as“Alice”) and node 310B (hereinafter referred to as“Bob”), wish to communicate over the data plane, both Alice and Bob invoke their respective data communication process 330. Moreover, it is envisaged that communication security will be enhanced by using Alice’s and/or Bob’s current entropy state to modify the data transmitted between Alice and Bob. As mentioned, the current entropy state is updated from time to time yet the updated entropy states are themselves not communicated; as such, the updated entropy states cannot be intercepted, and thus their evolution cannot be tracked, which enhances security of the communication channel between Alice and Bob.

Specific non-limiting examples of what is meant by“using Alice’s and/or Bob’s current entropy state to modify the data transmitted between Alice and Bob” are further described below, and may include (i) Alice signing the data intended for Bob with a signature that was generated based on Alice’s current entropy state (see“Enhanced security example: digital signature”); (ii) Alice and Bob encrypting the data in either direction of communication using an encryption key that was generated based on Alice’s and/or Bob’s current entropy state (see“Enhanced security example: blockchain transactions”). These non-limiting examples leading to enhanced security of communication between Alice and Bob will now be described. In the portion of the description to follow, it will be assumed that Alice’s and Bob’s entropy history tables 510, 530A have been created and are regularly updated through autonomous communications (e.g., “heartbeats”) occurring over the entropy plane (i.e., between the TA-side entropy state management process 350 of trust authority 340A and the node-side entropy state management process 320 of the various nodes in the trust group of trust authority 340A).

Enhanced security example: digital signature

Generally speaking, in this example, Alice wishes to send data to Bob and, in order to allow Bob to verify that the data was indeed sent by Alice, Alice“signs” the data. More specifically, Alice uses a token to sign the data, and this token is also separately generated by trust authority 340A (hereinafter referred to as a“witness”). To this end, Alice and the witness are configured to run a token generation protocol that produces the token from the current entropy state; however, neither the token nor the current entropy state are communicated over the data network 120. Alice then sends a“witnessed message” to Bob. ETpon receipt of the witnessed message, Bob can then request the token from the witness and use the received token to verify authenticity of Alice’s signature. In some business models, the witness may charge a fee for this verification Additional technical details regarding this non-limiting example application are now provided. With specific reference now to Fig. 7, there is shown an example system for transmission of a witnessed message WM from Alice to Bob in accordance with a non-limiting embodiment. It is assumed that Alice and the witness have securely built up respective entropy history tables 510, 530A with common content. It is recalled that each of the entropy history tables 510, 530A comprises entropy records, each of which includes a plurality of entries, which may include a time indicator entry, an entropy state entry and a hash entry. It is further assumed that a common entropy record is identified in both Alice’s and the witness’ entropy history tables 510, 530A. The common entropy record may be identified by, for example, agreeing on a common time indicator. The common entropy record identifies an entropy state, which for the purposes of the present example, will be referred to as the“shared entropy state at time t” (or simply“shared entropy state”, and denoted ¾), and which has a corresponding hash H _t. It is further noted that Bob does not have knowledge of either of the entropy history tables 510, 530A.

In a particular non-limiting embodiment, and with reference to the diagram in Fig. 8, steps involved in Alice generating a witnessed message WM from an original message M are now described. It is assumed that Alice is associated with a public-private key pair, of which the private key PR is maintained private by Alice and the public key PU is accessible to third parties, e.g., by consulting an online database. With reference, therefore, to Fig. 8:

• Alice initiates a token generation protocol TokenGen(*) to generate a token T from the shared entropy state ¾, i.e., T = TokenGen(E _t ). By way of non -limiting example, the token generation protocol may involve several steps:

Use of a pseudo random number generator (such as RC4 PRGA) to generate a pseudo random number R based on the shared entropy state ¾ for example, the shared entropy state ¾ may be input as the seed of the pseudo random number generator in order to generate the pseudo-random number R;

Use of a hash function (such as MD5 or SHA-2) to generate the token T from the pseudo random number R.

• Alice generates a signature SIG. This is done by first creating a digest D of a combination of the message M and the token T. In a simple example, the digest D can be generated as a hash function applied to a concatenation of the message M and the token T. Then, the digest D is encrypted with Alice’s private key PR to create the signature SIG.

• Alice creates a witnessed message WM with the message M and the signature SIG. In a non limiting embodiment, this can be done by concatenating the message M and the signature SIG to create the witnessed message WM.

• In addition, Alice informs the witness that a token was generated, and supplies the witness with the signature SIG (which, it is recalled, was generated from the message M and the token T), as well as the hash H _t corresponding to the shared entropy state E _t (obtained from Alice’s entropy history table 510). Alice may also provide the witness with Alice’s ID, or this may be inherent from the fact that the witness is receiving a communication from Alice.

• Based on Alice’s ID, the witness obtains Alice’s public key PU (for example, this could be stored in a database, which may be published online). Based on Alice’s public key PU, the witness retrieves a hash from entropy history table 530A corresponding to the shared entropy state ¾, and verifies that the retrieved hash matches H _t , the hash received from Alice. If not, then this could mean that Alice’s entropy history table 510 does not contain the same data for time indicator t as the witness’ entropy history table 530A. In some cases, this could be indicative of mere de-synchronization between the entropy history tables, but in other cases this could be indicative of a security breach. An alarm signal could therefore be generated by the witness, which could trigger further investigation into Alice’s credibility as a trusted network participant.

• Assuming, however, that there is indeed a match between the hash retrieved from the witness’ entropy history table 530A (for shared entropy state E _t ) and the hash H _t obtained from Alice, the witness initiates the token generation protocol TokenGen(*) from the shared entropy state E _t , which results in T = TokenGen(E _t ), namely the same token T as was generated by Alice.

• The witness updates a“token ledger” 3675 with the token T and the signature SIG, and stores both data elements in association with Alice’s public key PU (or other identifier of Alice). The token ledger 3675 may be implemented as a data structure, such as a table, linked list, etc., and may be stored in a database and physically residing in a computer memory. The token ledger 3675 may also log other details such as a message ID or session ID.

• The witness may then optionally inform Alice that its token ledger 3675 has been updated.

Consider now that the witnessed message WM reaches the recipient, Bob. It is recalled that the witnessed message WM includes a first part (the message M) and a second part (the signature SIG) - the two parts could be concatenated or combined in different ways to form the witnessed message WM.

In a particular non-limiting embodiment, steps involved in Bob validating / verifying the integrity of the received witnessed message WM are now described with reference to the diagram in Fig. 9:

• Bob extracts the signature SIG from the witnessed message WM.

• Bob provides the signature SIG (or a hash thereof) to the witness, together with Alice’s public key PU (or any other identifier of Alice that would allow the witness to obtain Alice’s public key PU).

• The witness obtains the token T by consulting the token ledger 3675 based on at least one of Alice’s public key PU and the signature SIG (or its hash) received from Bob.

• The witness sends the token T to Bob.

• Bob verifies integrity of the witnessed message WM using the token T. In particular:

• Bob extracts the message M from the witnessed message WM received from Alice, combines it with the token T received from the witness, and creates an expected digest D.

• Meanwhile, Bob applies Alice’s public key PU to the signature SIG, decrypting it, thereby to obtain a decrypted digest D’.

• Bob then compares the expected digest D to the decrypted digest D’. If there is a match, this will confirm that the message M in its current form was indeed sent by Alice. If not, this could mean that the message was tampered with, or that it was not actually sent by Alice. An action may be taken by Bob depending on the detected level of authenticity of the message received from Alice. Thus, at a high level, it can be said that Bob validates the witnessed message WM received from Alice by carrying out the following:

• providing at least a second part of the message (e.g., the signature SIG) to the witness and receiving a token T from the witness in response;

• obtaining a first data element (e.g., the digest D) by joint processing of a first part of the message (e.g., M) and the token (e.g., T); such joint processing could include hashing a combination of the first part of the message and the token)

• obtaining a second data element (e.g., the decrypted digest D’) by joint processing of the second part of the message (e.g., the signature SIG) using a key associated with Alice (e.g., decrypting the second part of the message (e.g., the signature SIG) using Alice’s public key, whereby the corresponding private key was used to encrypt the second part of the message (e.g., the signature SIG) and, more specifically to encrypt a result of joint processing, by Alice, of the first part of the message (e.g., the signature M) and the token (e.g., T), thereby to create the second part of the message (e.g., the signature SIG)); and

• validating the witnessed message by comparing the first data element (e.g., the digest D) and the second data element (e.g., the decrypted digest D’); note that if the validating is unsuccessful, a warning of some kind (e.g., signal) may be issued by Bob.

It is noted that the first data element (e.g., the digest D) and the second data element (e.g., the decrypted digest D’) match only when the token received from the witness matches the token originally used by Alice in creating the second part of the message (e.g., the signature SIG). These tokens (or, more precisely, this token) are both created from the same shared entropy state ¾. This shared entropy state was identified by the witness consulting a ledger based on a code (such as a hash H _t derived from the shared entropy state ¾) received from Alice.

The above-described process prevents a malicious party from generating a valid transaction on behalf of Alice, even if the malicious party gains access to Alice’s private key PR, and even if the malicious party also somehow guesses or gains access to the token T. This is because the malicious party does not have access to the entropy history tables 510, 530A, and therefore the malicious party would not know the shared entropy state E _t or its corresponding hash H _t. Thus, the malicious party cannot successfully instruct the witness to generate the correct token T that is eventually sent to a requesting recipient during the validating process.

Stated differently, Alice and the witness should have the capability to generate the same token because Bob relies on the witness for the token. If the tokens are different, Bob will be unable to verify the message. It is assumed that Alice and the witness share a privileged/secured relationship, which is enabled by the witness being a trust authority 340A for node 310A. Moreover, the witness will generate tokens when directed by Alice. The resulting signature may be more difficult to falsify than a conventional signature, even for quantum computers.

Thus, at a high level, it can be said that the witness is configured to obtain a code (such as the hash H _t ) and a signature from Alice, consult a first database (entropy history table 530A) to obtain entropy data (shared entropy state ¾) associated with the code, generate a token from the entropy data, store in a second database (token ledger 3675) an association between the token and the signature (and possibly also the identifier of Alice, such as a public key) and, later, transmit a message comprising the token in response to receipt of a request identifying at least the signature. However, consulting the first database to obtain the entropy data may be limited to situations where a match is confirmed between code obtained from Alice and a code associated with the identifier of Alice; otherwise an alarm signal may be issued.

Enhanced security example: blockchain transactions

The example system of Fig. 8 may similarly be used for publishing a“witnessed blockchain transaction” in accordance with a non-limiting embodiment. Specifically, the system again involves Alice and Bob (nodes) as well as the witness (trust authority). It is again assumed that Alice and the witness have securely built up respective entropy history tables 510, 530A with common content, beyond the reach of Bob. A common entropy record is identified and identifies an entropy state, which for the purposes of the present example, will again be referred to as the “shared entropy state” (and denoted ¾), and which has a corresponding hash H _t. For permissioned blockchains, the witness could be a higher permissioned blockchain node. For public blockchains, the recipient of transactions could be any miners for the proof of work. In these cases, the signature verifier is not the transaction recipient but any of the other miners. In this particular non-limiting embodiment, and with reference to the diagram in Fig. 10, steps involved in Alice generating a witnessed blockchain transaction WB from an original transaction payload/message B are now described. It is assumed that Alice is associated with a public- private key pair, of which the private key PR is maintained private by Alice and the public key PU is accessible to third parties, e.g., by consulting an online database. With reference, therefore, to Fig. 10:

• Alice initiates a token generation protocol TokenGen(*) to generate a token T from the shared entropy state ¾, i.e., T = TokenGen(E _t ). By way of non -limiting example, the token generation protocol may involve several steps:

Use of a pseudo random number generator (such as RC4 PRGA) to generate a pseudo random number R based on the shared entropy state ¾ for example, the shared entropy state ¾ may be input as the seed of the pseudo random number generator in order to generate the pseudo-random number R;

Use of a hash function (such as MD5 or SHA-2) to generate the token T from the pseudo random number R.

• Alice generates a signature SIG. This is done by encrypting a combination (e.g., concatenation) of the transaction payload/message B and the token T with Alice’s private key PR.

• Alice creates a witnessed blockchain transaction WB with a transaction ID, the transaction payload/message B and the signature SIG.

• In addition, Alice informs the witness that a token was generated, and supplies the witness with the signature SIG (which was generated form the message B and the token T), as well as the hash H _t corresponding to the current entropy state E _t (obtained from entropy history table 510). Alice may also provide the witness with Alice’s ID, or this may be inherent from the fact that the witness is receiving a communication from Alice.

• Based on Alice’s ID, the witness obtains Alice’s public key PU. Based on Alice’s public key PU, the witness retrieves a hash from entropy history table 530A corresponding to the shared entropy state E _t , and verifies that the retrieved hash matches H _t , the hash received from Alice. If not, then this could mean that Alice’s entropy history table 510 does not contain the same data as the witness’ entropy history table 530A. In some cases, this could be indicative of mere de-synchronization between the entropy history tables, but in other cases this could be indicative of a security breach. An alarm signal could therefore be generated by the witness, which could trigger further investigation into Alice’s credibility as a trusted network participant.

• Assuming, however, that there is indeed a match between the hash retrieved from the witness’ entropy history table 530A (for shared entropy state ¾) and the hash H _t obtained from Alice, the witness initiates the token generation protocol TokenGen(*) from the shared entropy state ¾, which results in T = TokenGen(E _t ), namely the same token T as was generated by Alice.

• The witness updates a“token ledger” 3975 with the token T and the signature SIG, and stores both in association with Alice’s public key PU (or other identifier of Alice). The token ledger 3975 may be implemented as a data structure, such as a table, linked list, etc., and may be stored in a database, and physically residing in a computer memory. The token ledger 3975 may also log other details such as transaction ID or session ID.

• The witness may then optionally inform Alice that the token ledger 3975 has been updated.

Consider now that Alice publishes the witnessed blockchain transaction WB to recipient Bob. It is recalled that the witnessed blockchain transaction WB includes the transaction ID, the transaction payload/message B and the signature SIG. Steps involved in Bob verifying the integrity of the witnessed blockchain transaction WB are similar to those already described with reference to the diagram in Fig. 9.

Enhanced security example: session key establishment

Reference is now made to Figs. 11A to 11C, which will demonstrate secure session key establishment between two nodes, Alice and Bob, belonging to a trust group associated with a trust authority 1140. It is assumed that Alice and the trust authority 1140 have securely built up matching entropy history tables with common content, and that a first common entropy record is identified in both Alice’s entropy history table and in the trust authority’s entropy history table for Alice. Analogously, it is assumed that Bob and the trust authority 1140 have securely built up matching entropy history tables with common content, and that a second common entropy record is identified in both Bob’s entropy history table and in the trust authority’s entropy history table for Bob.

Generally speaking, in this example, Alice and Bob wish to establish a unique session key for communicating with each other. More specifically, as shown in Fig. 11 A, the trust authority 1140 and Alice each generate token Tl (“Alice’s token”), whereas the trust authority 1140 and Bob each generate token T2 (“Bob’s token”). This can be done without sharing either Alice’s token Tl or Bob’s token T2 over the data network 120, simply by agreeing on a shared entropy state, and by deriving the tokens from the shared entropy state using an agreed-upon algorithm. A suitable algorithm may be TokenGen(*) described above, although this should not be considered a limitation, as other algorithms may be used. The shared entropy state between Alice and the trust authority 1140 may be E _A and the shared entropy state between Bob and the trust authority 1140 may be E _B. As such, Alice and the trust authority 1140 may run TokenGen(E _A ), whereas Bob and the trust authority 1140 may run TokenGen(E _B ).

The trust authority 1140 then generates a session token T3 from Alice’s and Bob’s tokens Tl, T2. For example, the session token T3 may be the exclusive OR (XOR) of Tl and T2. It is noted that the XOR operation allows Alice’s token Tl to be recoverable from Bob’s token T2 and the session token T3, and also allows Bob’s token T2 to be recoverable from Alice’s token Tl and the session token T3. Accordingly, the trust authority 1140 distributes the session token T3 to both Alice and Bob, allowing Alice to recover Bob’s token T2 and allowing Bob to recover Alice’s token Tl. Operations other than XOR that allow recoverability of Tl from T3 and T2, and recoverability of T2 from T3 and Tl, can be used.

With reference now to Fig. 11C, Alice and Bob, each of whom now has access to each other’s tokens, can then decide on a session key to use based on Alice’s token Tl and Bob’s token T2, depending on operational requirements. For example, both Alice and Bob may generate the session key from Alice’s token Tl (which by now is known to both Alice and Bob). Alternatively, the session key may be generated from Bob’s token T2, or from a function of both Alice’s and Bob’s tokens (e.g., a concatenation of Tl and T2).

The session key can then be used to encrypt communications between Alice and Bob. However, because the trust authority 1140 has access to both Alice’s token Tl and Bob’s token T2, it is possible for the trust authority 1140 to eavesdrop on communication between Alice and Bob despite use of the session key. To enhance security of this communication, and with reference to Fig. 11C, and by way of non-limiting example, Alice can share a secret 1160 with Bob peer using an alternate channel 1150, to the exclusion of the trust authority 1140. The alternate channel 1150 can be implemented, for example, by PKI or by using a different trust authority than the trust authority 1140. Of course, Bob could similarly share a secret with Alice.

Enhanced security example: secure web access

Consider now a specific non-limiting example of session key establishment, in the case where Bob represents a Web Server and Alice represents a User accessing the web server over the data network 120. As before, Alice (the User) and Bob (the Web Server) continue to belong to the trust group associated with the trust authority 1140 and that entropy history tables are maintained for the User and for the Web Server. Fig. 12 shows steps in a non-limiting process of secure web access.

At step 1210, the User generates a token T _A based on a selected entropy state E _A , which is associated with a hash H _A. The User sends a message to the trust authority 1140 requesting generation of a token. Accordingly, the User sends the hash H _A and indicates to the trust authority 1140 that the User wishes to communicate with the Web Server.

At step 1220, the trust authority 1140 looks up the correct entropy state based on the received hash H _a , and generates the token T _A based on the entropy state E _A. Knowing that the User wants to communicate with the Web Server, the trust authority 1140 accesses the entropy table for the Web Server, and selects an entropy state E _B (which is associated with a hash H _B ). The trust authority 1140 creates a token T _B from the entropy state E _B , and then creates a session token T _s from tokens T _A and T _B , in such a way that token T _A will be recoverable from tokens T _B and T _s. An XOR function may be suitable for this purpose, i.e., T _s = T _A XOR T _B. The trust authority 1140 sends a message to the Web Server, which message includes the identity of the User, the hash H _B (to allow the Web Server to know the correct entropy state) and the session token (to allow the Web Server to extract the User’s token T _A ).

At step 1230, the Web Server, which has received the message from the trust authority 1140, finds the entropy state E _B associated with hash H _B , generates the token T _B , then generates the token T _A from tokens T _B and Ts. At this point, both the User and the Web Server have knowledge of the token T _A .

At step 1240, which can happen after, before or during step 1230, the trust authority 1140 sends a message to the User with the session token T _s that was generated from tokens T _A and T _B .

At step 1250, the User generates the token T _B from tokens T _A and Ts. At this point, both the User and the Web Server also have knowledge of the token T _B .

At step 1260, the User and the Web Server choose a session key based on token T _A and/or token T _B . Additionally, the User and the Web Server may communicate independently of the trust authority 1140 to exchange a secret that further enhances security and prevents eavesdropping by the trust authority 1140.

Updating of entropy state

As has been previously described, the entropy state for each node is updated in the entropy history table of the node and in the entropy history table of the associated trust authority. By way of non-limiting example, consider node 310A and its associated trust authority 340A, each of which stores or has access to an entropy history table as previously described. Consider that the current time indicator is to and that the entropy state for the current time indicator is denoted E _0. Consider now that node 310A determines that it is time to update the entropy state, i.e., to determine the entropy state for a new time indicator t _B Determining that it is time to update the entropy state can be done autonomously by node 310A, or node 310A can be triggered to update the entropy state by trust authority 340 A.

One example non-limiting way of updating of the entropy state is now described with reference to Fig. 13.

Step 1304: Node 310A consults entropy history table 510 to obtain the current entropy state

E ₀ and the current hash H ₀ for the current time indicator t _0.

Step 1308: Node 310A obtains, generates or requests an“information nugget”, denoted g. A non-limiting example of the information nugget g could be a random or pseudo random number. Step 1310: Node 310A generates a new entropy state Ei from the current entropy state E ₀ and the information nugget g. For example, this could involve an XOR operation such as Ei= g (XOR) E _0. Of course, this is merely an example and should not be viewed as a limitation, as other operations are possible.

Step 1312: Node 310A generates a new hash Hi from the new entropy state Ei using a desired technique known to both node 310A and trust authority 340A.

Step 1316: Node 310A transforms the information nugget g into P(g). In one non-limiting example, transforming comprises PKI encryption using a public key of the trust authority 340A. In another non-limiting example, transforming the information nugget g into P(g) comprises symmetric encryption using the current entropy state E ₀ as the key. In a further non-limiting example, an encoding mapping is used for transforming the information nugget g into P(g) , as is described in U.S. Patent Application Serial No. 15/796,577 and International Patent Application Serial No. PCT/CA2018/051339 for example, but without being limited to these approaches.

Step 1318: Node 310A sends an update message 1360 to trust authority 340A. The update message 1360 includes the current hash H ₀ , as well as the transformed version of the information nugget, namely P(g), and the new hash Hi. The update message 1360 may also include an identifier of node 310A to facilitate processing by trust authority 340A.

Those skilled in the art will appreciate that in an alternative embodiment, step 1316 is omitted, and instead of transmitting P(g) at step 1318, it is possible to transmit the information nugget g, without transforming it in any of the above-described ways, but rather to transmit the information nugget g from node 310A to trust authority 340A over a secure out-of-band channel.

Step 1320: Trust authority 340A receives the current hash H _0, as well as the transformed version of the information nugget, P(g), and the new hash Hi. Based on the current hash H ₀ , trust authority 340A consults entropy history table 530A to find the corresponding entropy state, namely E _0.

Step 1324: Trust authority 340A recovers the information nugget g by decrypting P(g) using, e.g., the private key of the trust authority 340A. Of course, if the information nugget g were received by Bob over, say, an out-of-band channel, the recovery action could be omitted.

Step 1326: Trust authority 340A creates a candidate new entropy state Ei _* from the current entropy state E ₀ and the information nugget g in the same manner as was described earlier with respect to node 310A at step 1310. For example, as previously described, this could involve an XOR operation such as Ei _* = g (XOR) E _0. Of course, this is merely an example and should not be viewed as a limitation, as many other types of operations are possible.

Step 1327: Trust authority 340A generates a candidate new hash Hi _* from the candidate new entropy state Ei _* using the known technique.

Step 1328: Trust authority 340A compares the candidate new hash Hi _* with the new hash Hi that was received from node 310A in the update message 1360. If there is no match, this could be indicative of a security breach. If there is a match, trust authority 340A sends an acknowledgement message 1370 to node 310A.

Step 1330: Node 310A receives the acknowledgement message 1370 from trust authority

340A, updates entropy history table 510 with the new entropy state Ei and the new hash Hi for the new time indicator h, and sends back a completion message 1380.

Step 1332: Trust authority 340A receives the completion message 1380 from node 310A, and updates entropy history table 530A with the new entropy state Ei and the new hash Hi for the new time indicator h.

Both entities (node 310A and trust authority 340A) now have their entropy history tables updated. A further trigger, timer or heartbeat, may be set in order to carry out the next update phase. Of course, in the above description, updating of either entropy history table may occur as soon as the new entropy state Ei and new hash Hi have been computed, without waiting for further messages to be received.

From the foregoing, it will be noticed that each entropy state depends on the previous entropy state, which depends on the one before that, etc. As long as the peers agree on the time indicator, each peer will be able to access the same entropy state, yet without either one of them having received it or transmitted it over the data network 120.

It should be appreciated that a somewhat different process is followed when generating the initial entropy state E ₀ associated with initial time indicator to. During this preliminary phase, synchronization of the entropy history table 530A (at trust authority 340A) and the entropy history table 510 (at node 310A) may be controlled by trust authority 340A.

A first non-limiting embodiment for carrying out the preliminary phase is now described with reference to Fig. 14. It is assumed that a public-private key pair (PUK _A , PRK _A ) is associated with node 310A. Trust authority 340A is assumed to have knowledge of the public key PUK _A but not the private key PRK _A .

Step 1430: Trust authority 340A selects, generates or otherwise obtains an initial entropy state E ₀ and encrypts it with the public key PETf _A of node 310A, which gives PU(Eo).

Step 1440: Trust authority 340A sends PET(E ₀ ), the encrypted version of the initial entropy state Eo, to node 310 A.

Step 1450: Node 310A decrypts the initial entropy state E ₀ using its private key PRK _A , which is known to node 310A but not trust authority 340A. Both entities now share the initial entropy state E ₀ .

Step 1460: Node 310A and trust authority 340A produce the initial hash H ₀ using a common algorithm and update their respective entropy history tables 510, 530A with the initial hash H ₀ and the initial entropy state E ₀ .

At this point, node 310A and trust authority 340 A each have knowledge of the initial entropy state E ₀ .

A second non-limiting embodiment for carrying out the preliminary phase is now described with reference to Fig. 15. Specifically, in this embodiment, node 310A has the ability to communicate with trust authority 340 A not only over the data network 120 but also over an alternate channel 1500. In an embodiment, the alternate channel 1500 is an out-of-band (OOB) channel, which is out-of-band in that it does not utilize the data network 120. An example of an OOB channel may be a cellular link established over the public switched telephone network (PSTN), or an NFC link. With reference to Fig. 15, therefore, the flow of operation may be as follows:

• Node 310A generates an identifier QID and sends a message 1580 containing the identifier QID to trust authority 340 A.

• Trust authority 340A returns a message 1585 to node 310A, as a form of acknowledgement of message 1280.

• Node 310A generates or obtains the initial entropy state E _0.

• Node 310A then generates a code 1590 (e.g., a QR code or hash code) from the identifier QID and the initial entropy state E _0. It is to be understood that knowledge of the identifier QID and the code 1590 should allow recovery of the initial entropy state E _0.

• Node 310A sends a message 1595 containing the code 1590 to trust authority 340A over the OOB channel 1500.

• Trust authority 340A receives the message 1595 and recovers the initial entropy state E ₀ from the code 1590 based on Bob’s prior knowledge of the identifier QID.

At this point, node 310A and trust authority 340 A each have knowledge of the initial entropy state E _0.

General

In the above, reference was made to transforming an information nugget g using an encoding mapping. In some embodiments, which are not to be considered limiting, the transforming may correspond to a process of converting an N-bit input segment into an N-bit output segment using the encoding mapping expressed as a 2 ^N -by-2 ^N permutation matrix, as described by way of non limiting example in ET.S. Patent Application Serial No. 15/796,577 and International Patent Application Serial No. PCT/CA2018/051339. Specifically, an input index is determined as the (decimal) value of the particular N-bit input bit segment. Then, an output index is determined based on the input index and the encoding mapping. Finally, the binary representation of the output index becomes the N-bit output segment. The encoding mapping, namely the input-output configuration of the 2 ^N -by-2 ^N permutation matrix, may refer to the“entropy state” and may be represented as a states array S[2 ^N ] In a non-limiting implementation, the encoding mapping (for example, the permutation matrix) can be configured with both the current entropy and a message-based SALT/initial vector to enhance the communication security. The SALT/initial vector is controlled at the App level and is combined with the key (shared secret) to configure the encoding mapping. As such, the SALT/initial vector can be sent to the recipient together with encoded message for decoding the message.

The node-side entropy state management process and the TA-side entropy state management process communicate with one another over the so-called entropy plane. The entropy plane may be implemented at various places in the protocol stack. For example, with reference to Fig. 16, these entropy state management processes may be implemented at the application layer through an application programming interface API. In other embodiments, the entropy state management processes may be implemented at the transport layer as an extension to TLS.

Various operational embodiments are provided herein, including embodiments in which one or more of the operations described may correspond to computer readable instructions stored on one or more computer readable media, which if executed by a computing device, will cause the computing device to perform the operations described. The order in which some or all of the operations are described should not be construed as to imply that these operations are necessarily order-dependent. Alternative ordering will be appreciated by one skilled in the art having the benefit of this description. Further, it will be understood that not all operations are necessarily present in each embodiment provided herein.

Finally, although the disclosure has been shown and described with respect to one or more implementations, equivalent alterations and modifications will occur to others skilled in the art based upon a reading and understanding of this specification and the annexed drawings. The disclosure includes all such modifications and alterations and is limited only by the scope of the following claims. In particular regard to the various functions performed by the above described components (e.g., elements, resources, etc.), the terms used to describe such components are intended to correspond, unless otherwise indicated, to any component which performs the specified function of the described component (e.g., that is functionally equivalent), even though not structurally equivalent to the disclosed structure which performs the function in the herein illustrated exemplary implementations of the disclosure. In addition, while a particular feature of the disclosure may have been disclosed with respect to only one of several implementations, such feature may be combined with one or more other features of the other implementations as may be desired and advantageous for any given or particular application.