EP3701664A1 - Methods and systems for secure data communication - Google Patents
Methods and systems for secure data communicationInfo
- Publication number
- EP3701664A1 EP3701664A1 EP18870501.6A EP18870501A EP3701664A1 EP 3701664 A1 EP3701664 A1 EP 3701664A1 EP 18870501 A EP18870501 A EP 18870501A EP 3701664 A1 EP3701664 A1 EP 3701664A1
- Authority
- EP
- European Patent Office
- Prior art keywords
- bit
- message
- mapping
- segments
- computer
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
- H04L9/3236—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions
- H04L9/3239—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions involving non-keyed hash functions, e.g. modification detection codes [MDCs], MD5, SHA or RIPEMD
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/04—Payment circuits
- G06Q20/06—Private payment circuits, e.g. involving electronic currency used among participants of a common payment scheme
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/38—Payment protocols; Details thereof
- G06Q20/381—Currency conversion
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/38—Payment protocols; Details thereof
- G06Q20/382—Payment protocols; Details thereof insuring higher security of transaction
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/38—Payment protocols; Details thereof
- G06Q20/382—Payment protocols; Details thereof insuring higher security of transaction
- G06Q20/3821—Electronic credentials
- G06Q20/38215—Use of certificates or encrypted proofs of transaction rights
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/06—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols the encryption apparatus using shift registers or memories for block-wise or stream coding, e.g. DES systems or RC4; Hash functions; Pseudorandom sequence generators
- H04L9/0618—Block ciphers, i.e. encrypting groups of characters of a plain text message using fixed encryption transformation
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
- H04L9/0816—Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
- H04L9/0819—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s)
- H04L9/0822—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s) using key encryption key
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/50—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols using hash chains, e.g. blockchains or hash trees
-
- H—ELECTRICITY
- H03—ELECTRONIC CIRCUITRY
- H03M—CODING; DECODING; CODE CONVERSION IN GENERAL
- H03M7/00—Conversion of a code where information is represented by a given sequence or number of digits to a code where the same, similar or subset of information is represented by a different sequence or number of digits
Definitions
- the present invention relates in general to data protection and, in particular, to data encoding and decoding.
- a computer-implemented method comprising:
- N being an integer greater than one
- a non-transitory computer- readable storage medium comprising computer-readable instructions which, when executed by a processor, cause the processor to carry out a method that comprises:
- N being an integer greater than one
- a computer-implemented method comprising:
- N being an integer greater than one
- a non-transitory computer- readable storage medium comprising computer-readable instructions which, when executed by a processor, cause the processor to carry out a method that comprises: - receiving an input message comprising N-bit input segments, N being an integer greater than one;
- a non-transitory computer- readable storage medium comprising computer-readable instructions which, when executed by a processor, cause the processor to carry out a method that comprises encoding input segments of data into output segments of data of the same size using a one-to-one mapping of dimensionality greater than the size of the segments.
- a method comprising encoding input segments of data into output segments of data of the same size using a one-to-one mapping of dimensionality greater than the size of the segments.
- a non-transitory computer- readable storage medium comprising computer-readable instructions which, when executed by a processor, cause the processor to carry out a method that comprises using a permutation mapping to encode individual first sets of bits of an input bit stream into corresponding same-sized second sets of bits of an output bit stream, the permutation mapping being such that, for most of the possible corresponding pairs of first and second sets, the relative proportion of ones and zeroes is different between the two sets in the pair.
- a non-transitory computer- readable storage medium comprising computer-readable instructions which, when executed by a processor, cause the processor to carry out a method for a recipient to validate a message received from a sender, the message including a first part and a second part, wherein the method comprises:
- a computer-implemented method executed by a witnessing entity comprising:
- a non-transitory computer- readable storage medium comprising computer-readable instructions which, when executed by a processor, cause the processor to carry out a method that comprises:
- a computer-implemented method of synchronizing an Internet-enabled appliance with an application device comprising: - at the application device:
- an IoT system comprising:
- an application device comprising a processing and networking capabilities configured for:
- an appliance connected to the application device over the Internet and comprising processing and networking capabilities configured for:
- Fig. 1 is a block diagram showing a sending device, a receiving device and a channel.
- Fig. 2 is a flowchart showing steps in a data encoding process, in accordance with a non- limiting embodiment.
- Fig. 3 is a conceptual block diagram, showing various steps in the data encoding process, in accordance with a non-limiting embodiment.
- Figs. 4A to 4C are block diagrams showing various ways to carry out one of the steps in Fig. 2, in accordance with various non-limiting embodiments.
- Fig. 5 is a block diagram, showing various steps in the data encoding process, in the context of a specific example of a non-limiting embodiment.
- Figs. 6A-6D are block diagrams showing distribution of the encoding and decoding mappings to the sending and receiving devices, respectively, in accordance with various non-limiting embodiments.
- Fig. 7A-7C illustrate how certain embodiments may be applied to an application loading scenario for an operating system (OS).
- OS operating system
- Fig. 8 schematically shows the relative size of memory space and entropy space.
- Fig. 9 is a block diagram showing communication from one peer to another over the Internet.
- Fig. 10 is a schematic block diagram showing generation and exchange of an initial secret between two peers.
- Fig. 11 is a bock diagram showing communication from one peer to another over the Internet and over an alternate channel.
- Fig. 12 is a block diagram further detailing the communication in Fig. 11, showing specific messages exchanged over the Internet and over the alternate channel.
- Fig. 13 is a message flow diagram showing a message exchange among two peers, Alice and Bob, and a server.
- Figs. 14A and 14B illustrate processes for generating permutation matrices from an initial secret.
- Fig. 15 is a message flow diagram showing a message exchange among two peers, Alice and Bob, and a server that issues seeds, resulting in Alice and Bob both having access to an encryption key QK.
- Fig. 16 is a variant of Fig. 15, in which the seeds are broadcast by the server.
- Figs. 17A-17C are variants of communication between two peers.
- Fig. 18 is a schematic diagram that conceptually illustrates transactions in a blockchain.
- Fig. 19 is a schematic block diagram that illustrates a process of encoding an initial secret with a blockchain transaction as well as a process for retrieving the initial secret from the transaction.
- Fig. 20 is a schematic block diagram illustrating secure file storage on a blockchain.
- Fig. 21 is a table showing a relationship between the proportion of zeroes and ones in an 8-bit input segment and the likelihood of occurrence of an input segment having such proportion.
- Fig. 22 is a network diagram of an Internet-of-things (IoT) environment.
- IoT Internet-of-things
- Fig. 23 is a schematic diagram showing an appliance in the IoT environment.
- Fig. 24 is a block diagram illustrating a broker implementing a subscribe-publish communication paradigm in the IoT environment.
- Fig. 25 is a schematic diagram showing a PUBLISH message containing data, for use in the IoT environment.
- Fig. 26 is a schematic diagram illustrating transmission of a PUBLISH message containing data in the IoT environment.
- Fig. 27 is a schematic diagram illustrating transmission of a PUBLISH message containing a seed in the IoT environment.
- Fig. 28 is a block diagram of an application device in the IoT environment.
- Fig. 29 is a schematic block diagram illustrating transmission of a message containing a seed, from the application device to the appliance in the IoT environment
- Fig. 30 is a schematic diagram showing a PUBLISH message containing a seed, for use in the IoT environment.
- Fig. 31 is a schematic diagram showing an alternate message format for use in an alternate IoT environment.
- Fig. 32 is a block diagram showing a security enhancement involving dynamic spreading using a stream cipher.
- Fig. 33A is a block diagram of a communication system with the capability of building an Entropy History Table by two peers.
- Fig. 33B is a flowchart illustrating a preliminary phase in the context of building an Entropy History Table by two peers.
- Fig. 34 is a flowchart illustrating an update phase in the context of building an Entropy History Table by two peers.
- Fig. 35 shows a system for communicating a witnessed message.
- Fig. 36 is a diagram showing generation of a witnessed message.
- Fig. 37 is a diagram showing receipt of a witnessed message.
- Fig. 38 shows a system for publishing a witnessed blockchain transaction.
- Fig. 39 is a diagram showing generation of a witnessed blockchain transaction.
- Fig. 40 is a block diagram showing a security enhancement involving multi-level quantropization.
- Fig. 41 is a block diagram showing a security enhancement involving bit position shuffling.
- Fig. 42 is a block diagram showing a security enhancement involving block quantropization.
- Figs. 43A and 43B are block diagrams showing a security enhancement involving dynamic spreading.
- Fig. 1 shows a communication system that may be configured to incorporate an example non- limiting embodiment of the present invention.
- the system includes a sending device 110, a receiving device 120 and a channel 130 between the sending device 110 and the receiving device 120.
- the sending device 110 and the receiving device 120 may each be implemented within a mobile phone, smartphone, laptop, desktop, on-board vehicle computer, internet-enabled appliance, etc.
- the sending device 110 may release a signal 140 to the receiving device 120 over the channel 130.
- the signal 140 may be a modulated signal that carries digital data that has been encoded by elements of the sending device 110.
- the channel 130 may be any suitable communication channel physically implemented using any suitable medium including one or more of wired, RF, fiber optic, free-space optical, acoustic, etc.
- the channel 130 may be implemented logically as a path over one or more data networks including but not limited to an intranet, a virtual private network and the Internet.
- the receiving device 120 may also release a signal (not shown) containing data for the sending device 110 onto the channel 130 such that both the sending device 110 and the receiving device 120 are in bidirectional communication over the channel 130.
- a description of the generation of a signal by the receiving device 120 for transmission towards the sending device 110 will not be provided, as it would closely match the description of the generation of the signal 140.
- the sending device 110 uses electricity (e.g., DC or AC electricity from a battery, generator, inverter, power lines, photovoltaic cell or electrical transformer) to effect a transformation or change on an input signal carrying an input bit stream, in order to produce an output signal carrying an output bit stream.
- electricity e.g., DC or AC electricity from a battery, generator, inverter, power lines, photovoltaic cell or electrical transformer
- the sending device 110 includes a processing entity 112 and a memory 114 that stores computer-readable instructions.
- the memory 114 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 processing entity 112 is configured to execute the computer-readable instructions in the memory 114.
- the processing entity 112 of the sending device 110 causes the sending device 110 to implement a variety of processes, including data processes and control processes.
- Examples of a processing entity may include electronic components such as a computer processor on a microchip, or a quantum computer.
- An example of a process that may be implemented by the processing entity 112 includes a data encoding process, described herein below in further detail.
- the data encoding process may be encoded as a subset 116 of the computer-readable instructions in the memory 114.
- An input/output (I/O) 118 enables the processing entity 112 to communicate externally and may include a screen (e.g., touchscreen), keyboard/mouse, network interface device/card (e.g., to support NFC, WiFi, Ethernet or cellular / GSM / LTE communications), USB port(s), etc.
- a screen e.g., touchscreen
- keyboard/mouse e.g., keyboard/mouse
- network interface device/card e.g., to support NFC, WiFi, Ethernet or cellular / GSM / LTE communications
- USB port(s) e.g., USB port(s), etc.
- the receiving device 120 also uses electricity to effect a transformation or change on an input signal carrying an input bit stream, in order to produce an output signal carrying an output bit stream.
- the receiving device 120 includes a processing entity 122 and a memory 124 that stores computer-readable instructions.
- the processing entity 122 is configured to execute the computer-readable instructions in the memory 124.
- the processing entity 122 of the receiving device 120 causes the receiving device 120 to implement a variety of processes, including data processes and control processes. Examples of a processing entity may include electronic components such as a computer processor on a microchip, or a quantum computer.
- An example of a process that may be implemented by the processing entity 122 includes a data encoding process, described herein below in further detail.
- the data decoding process may be encoded as a subset 126 of the computer-readable instructions in the memory 124.
- An input/output (I/O) 118 enables the processing entity 122 to communicate externally and may include a screen (e.g., touchscreen), keyboard/mouse, network interface device/card (e.g., to support NFC, WiFi, Ethernet or cellular / GSM / LTE communications), USB port(s), etc.
- Components of the sending device 110 may be connected by various interconnects, such as a bus.
- interconnects may include a Peripheral Component Interconnect (PCI), such as PCI Express, a Universal Serial Bus (USB), Firewire (IEEE 1394), an optical bus structure, and the like.
- PCI Peripheral Component Interconnect
- USB Universal Serial Bus
- Firewire IEEE 1394
- optical bus structure an optical bus structure, and the like.
- components of the sending device 110 and the receiving device 120 may be interconnected by a network.
- the memory 114 (124) may be comprised of multiple physical memory units located in different physical locations interconnected by a network.
- the memory 114 (124) may be volatile (such as RAM, for example), non-volatile (such as ROM, flash memory, etc., for example) or some combination of the two.
- the computer readable instructions stored in the memory 114 (124) may be implemented as program modules, such as functions, objects, Application Programming Interfaces (APIs), data structures, and the like, that perform particular tasks or implement particular abstract data types.
- the functionality of the computer readable instructions may be combined or distributed as desired in various environments.
- the sending device 110 and the receiving device 120 may be the same computer
- the channel 130 may be internal circuitry of the computer
- the processing entities 112, 122 may be the same processing entity
- the memories 114, 124 may be a common computer memory
- the subsets 116, 126 may be different subsets of the common computer memory.
- bit stream generally encompasses a sequence of binary digits.
- a "bit stream” may include a sequence of bits that represents a stream of data, transmitted continuously over a communications path.
- bit stream may encompass a bit string or an ordered collection of bits that may be encoded into, or reside on, a computer-readable medium, such as the bits that define a file stored on a solid state or magnetic drive.
- a "bit stream” may include part of a digital message that may be formatted as an email, a text message, an instant message, an image, a video, a document in a format such as Word, PDF, etc. or in any other suitable way.
- N is an integer at least as great as 1 and typically would be higher for added security.
- N may be 2, 4, 6, 8 or at least as great as 10, while in other embodiments, N may be at least as great as 20.
- N may be 12, 13 or 14.
- the system size may be fixed, or may be dynamically changed over time as will be described later on.
- the processing entity 112 encodes input segments of data into output segments of data of the same size using a one-to-one mapping of dimensionality greater than the size of each segment.
- the processing entity 112 obtains data indicative of a one-to-one mapping between 2 N possible input indexes and 2 N possible output indexes where, it is recalled, N represents the system size. To disambiguate this mapping from other mappings described elsewhere, the mapping obtained at step 220 will be referred to herein as the "encoding mapping".
- the encoding mapping may be expressed in different ways.
- the encoding mapping may thus represent a one-to-one association between each of the values from 0 to 2 N - 1 and another (typically but not necessarily) different value between 0 and 2 N - 1.
- the encoding mapping take the form of a 2 N -by-2 N matrix "P", where each row and each column contains a single “1", and the rest of the matrix elements (of which there are 2 2N -2 N ) are "0".
- a matrix may be referred to as a "binary permutation matrix”, and may be stored in the memory 114.
- the encoding mapping may take the form of a switch fabric input- output correspondence table that associates each of 2 N switch inputs to one of 2 N switch outputs. The switch fabric input-output correspondence table may be stored in the memory 114.
- the encoding mapping may be stored in the memory 114 and suitably accessed and interpreted by the processing entity 112, are within the scope of the present invention.
- the encoding mapping may be fixed, or may be dynamically changed over time as will be described later on.
- the processing entity 112 subdivides or separates the input bit stream 310 in Fig 3 into a plurality of input bit segments 320 in Fig 3, such that each of the input bit segments 320 is configured to have the system size, i.e., each of the input bit segments 320 is N bits long.
- This can be referred to as a disassembly process. It is noted that whereas a customary way to separate binary data is in groups of 8 bits (i.e., bytes), the value of N need not be 8 or a multiple thereof, and therefore the input bit segments 320 resulting from execution of step 230 are not necessarily a multiple of 8 bits long.
- the processing entity 112 produces a plurality of output bit segments 330, where each of the output bit segments 330 corresponds to a respective one of the input bit segments 320.
- Each of the output bit segments 330 is configured to have the system size and is therefore N bits long, i.e., just like the input bit segments 320.
- the contents of a given one of the output bit segments 330 is related to the contents of the respective one of the input bit segments 320 by the encoding mapping as will be described herein below. Specifically, for a particular N-bit input bit segment, 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 corresponding N-bit output segment is set to the binary representation of this output index. This can be referred to as a quantropization process.
- the look-up table 402 could be stored in the memory 114, wherein each of 2 N input indexes (the "x" column) is associated with a single output index (the "y" column).
- step 240 can involve accessing the look-up table 402 in the memory 114, based on an input index derived as the value of a particular N-bit input bit segment, so as to obtain an output index.
- step 240 can involve calling a subroutine that executes a vector-matrix multiplication between g and P.
- the subroutine may be stored as computer-readable instructions stored in the memory 114 and executable by the processing entity 112.
- the outcome of the vector-matrix multiplication will be a 1 x 2 N (i.e., 1 x 8) vector "g*" that contains a "1" element in the column that represents the output index.
- a hardware or software switch fabric 400 having 2 N inputs 410 and 2 N outputs 420 may be implemented within the sending device 110 and the encoding mapping may be represented as a switch fabric input-output correspondence table 401 for the switch fabric 400, as may be stored in the memory 114.
- the inputs 410 correspond to bit positions in successive 2 N xl input arrays (each containing only one "1" element at the position of the input index, the rest being zeroes) formed from corresponding N-bit input bit segments 320.
- the result is a succession of 2 N xl output arrays at the outputs 420 of the switch fabric 400. Each such output array contains only one "1" element at the position of the output index, the rest being zeroes.
- the decimal value of the position of the output index is converted into binary form, thus yielding the corresponding one of the N-bit output bit segments 330.
- the processing entity 112 may concatenate or combine multiple (e.g., successive) ones of the output bit segments 330 into an output bit stream 340, which may itself then be organized into bytes (or any other convenient grouping) and sent out onto the channel 130, e.g., they may be carried by the signal 140 after modulation into a modulated signal.
- modulated signal may include a signal that has one or more of its characteristics set or changed in such a manner as to encode information in the signal.
- an input data stream includes a sequence of hex bytes whose values are, from right to left, 57, 85, 33, 30, etc.
- the hex bytes can be broken down into bits, thus creating an input bit stream.
- the first 14-bit input bit segment is 00010101010111, which has a decimal value of 1367
- the next 14-bit input bit segment is 00000011001110, which has a decimal value of 206, and so on.
- the encoding mapping is first applied to decimal value 1367.
- the input bit segment had seven “l”s and the output bit segment only has four “l”s. This shows that the encoding mapping does not merely represent a permutation of the bits in the input bit segment. In fact, a given density of "l”s in the input bit segment may produce any given density of "l”s in the corresponding output bit segment, depending on the specifics of the encoding mapping.
- the change in the bit pattern between a particular N-bit input bit segment and the corresponding N-bit output bit segment can be manifested, in a computer system, as a difference in voltage, current or other physical characteristics of the signal used to store and/or transmit the bit pattern in question.
- the permutation mapping is of a dimensionality greater than the size of the input and output segments.
- the permutation mapping P can be of a size 2 N by 2 N , if not greater.
- an ordered set of input bits is obtained.
- the processing entity 112 breaks down (disassembles) the ordered set of input bits into a plurality of N-bit input segments.
- N-bit output segments corresponding to respective ones of the N-bit input segments are produced by: (i) expanding each of the N-bit input segments into a 2 N -bit input segment, applying the 2 N -by-2 N mapping to the 2 N -bit input segment to determine a 2 N -bit output segment, compressing the 2 N -bit output segment into an N-bit output segment.
- an ordered set of output bits is formed using the resulting N-bit output segments and the ordered set of output bits can be released onto a physical medium or stored in the memory.
- the signal 140 travels along the channel 130 and reaches the receiving device 120. Certain pre-processing may be required to account for channel loss, distortion and other factors. Ultimately, however, the receiving device 120 executes a data decoding process that is virtually identical to the data encoding process performed by the sending device 110, except that it is performed with a decoding mapping rather than with an encoding mapping.
- the decoding mapping is the inverse of the encoding mapping so as to recover the originally encoded data.
- the N-bit input bit segment to the data encoding process was an "unencoded bit segment" (with the N-bit output bit segment resulting from application of P to the unencoded bit segment being an "encoded bit segment")
- the N-bit input bit segment to the data decoding process is the encoded bit segment, and furthermore if the binary permutation matrix Q applied by the data decoding process is the transpose of P
- the N-bit output bit segment resulting from the data decoding process will be the original, unencoded bit segment. That is, the original N-bit input bit segments are recovered after the decoding process. They can then be assembled into a string of bits that can then be suitably resized (e.g., as bytes).
- the encoding and decoding mappings may be represented as a pair of symmetric permutation matrixes P, Q, each being the transpose of the other, one of which is used in encoding and the other of which is used in decoding.
- the encoding and decoding mappings may be expressed as a single binary permutation matrix B together with additional an indicator (or "flag") being provided to the sending device 110 and the receiving device 120 to instruct one of the two devices to use B and the other to use B T .
- both the data encoding and decoding processes do not significantly add to the computational burden of the processing entities 112, 122 in the sending and receiving devices 110, 120.
- the data encoding and decoding processes involve operations such as (i) index mapping from input index to output index or (ii) sparse vector-matrix multiplication, either of which may be efficiently handled by modern computer systems and processing entities.
- CPU usage and energy costs of encoding and decoding may be kept low, potentially resulting in longer battery life, less latency and freeing up processing resources for other tasks. This contrasts with more complex numerical methods such as prime number factorization.
- each set of N original input bits can be said to reside in memory in a "bit space" 810 of size N.
- the information carried by these N original input bits can be said to exist in an "information space” 820 of size 2 N . That is to say, N bits can be used to express 2 values or other information elements.
- the size of the corresponding encoding mapping e.g., permutation matrix or switch fabric input- output correspondence table or look-up table
- the dimensionality of the encoding mapping is 2 N . This means that, if one represents the encoding mapping as a binary permutation matrix, there are (2 N )!
- the input-output configuration of a particular 2 N - by-2 N encoding mapping used in quantropization can be referred to as an "entropy state", which can be represented in some non-limiting embodiments as a states array S[2 N ], although one may use a multitude of other ways to express the encoding mapping.
- each possible 2 N input bit stream does indeed map deterministically to a single 2 N output bit stream, this mapping does not arise from mere permutation of the bits in the input bit stream; rather it results from selection of an encoding mapping in a much larger space (i.e., the selection of one 2 N x2 N matrix in the space of 2 N x2 N matrices), which makes it more economical for a hacker to "guess" the N-bit value of the original input bit segment corresponding to an observed N-bit output bit segment, than to try to find the "correct" encoding mapping over any reasonable observation period.
- This combination of low computational complexity, low latency and enhanced security against intrusion / hacking, provided by certain embodiments described herein, may help achieve high-bandwidth, real-time, quantum-secure communications.
- FIG. 9 shows two peers, Alice and Bob, each of which can be a laptop, smartphone, Internet-enabled appliance, vehicle electronic control unit (ECU), web server, etc.
- Alice has the role of the "sending device” 110 of Fig. 1 and, through execution of the subset of instructions 116, implements a plurality of functional modules (e.g., a disassembler 920A, a quantropizer 930A, a packager 940A and a control module 980A), which will be described herein below.
- Bob has the role of the "receiving device” 120 of Fig.
- Alice receives information segments (e.g., plain text input bits), which are then disassembled by the disassembler 920A into segments of a system size N (e.g., step 230 in Fig. 2).
- the N-bit input segments are processed by the quantropizer 93 OA into corresponding N-bit output segments according to an encoding mapping (e.g., a permutation matrix P) of size 2 N by 2 N (e.g., step 240 in Fig. 2).
- the resulting N-bit output segments are packaged into a suitable format by a packager 940A (e.g., step 250 in Fig.
- Bob includes the depackager 950B, which depackages the received quantropized data into N-bit input segments.
- the dequantropizer 960B applies the decoding mapping (e.g., P T ) to obtain N-bit output bit segments. These are then assembled into suitable information segments (e.g., plain text output bits) by the assembler 970B.
- control module 980A is responsible for determining the encoding mapping (e.g., permutation matrix P) to be used by the corresponding quantopizer 930A (e.g., steps 210 and 220 in Fig. 2)
- control module 980B is responsible for determining the decoding mapping (e.g., permutation matrix P T ) to be used by the corresponding dequantropizer 930B.
- the permutation matrix P is used by the sending device 110 and the transpose of this matrix, namely P T , is used by the receiving device 120.
- P T is derivable from P, it is possible for both devices to be advised of just the permutation matrix P as well as to be advised of a flag (or other indicator) that tells the sending device 110 to use P in its data encoding process (i.e., without transposing it), and that tells the receiving device 120 to use P T in its data decoding process.
- the reverse is also possible (i.e., using P T in the data encoding process and P in the data decoding process).
- the sending device 110 uses ⁇ P(x,y) ⁇ and the receiving device 120 uses ⁇ P _1 (x,y) ⁇ .
- ⁇ P _1 (x,y) ⁇ is derivable from ⁇ P(x,y) ⁇ (as it equals to ⁇ P(y,x) ⁇ )
- both devices it is possible for both devices to be advised of just the set ⁇ P(x,y) ⁇ as well as to be advised of a flag (or other indicator) that tells the sending device 110 to use ⁇ P(x,y) ⁇ in its data encoding process, and that tells the receiving device 120 to use ⁇ P(y,x) ⁇ in its data decoding process.
- the reverse is also possible (i.e., using ⁇ P(y,x) ⁇ in the data encoding process and ⁇ P(x,y) ⁇ in the data decoding process).
- the encoding mapping is represented by a binary permutation matrix P and the decoding mapping is represented by a binary permutation matrix P T ; however, lookup tables or the previously described sets ⁇ P(x,y), ⁇ P(y,x) ⁇ ⁇ could also have been used.
- P specific matrix
- P(y,x) a common permutation matrix
- the sending device 110 generates the encoding mapping P and stores it in the memory 114.
- the sending device may send P T to the receiving device 120 in a signal 615 during an initialization phase.
- a handshaking protocol may be executed by the sending device 110 and the receiving device 120.
- This handshaking protocol may be securely implemented using current encryption technologies such as AES or DES.
- the handshaking protocol may be securely implemented using the techniques taught herein with a predefined system size M and default encoding (and decoding) mapping that is known and/or made available to the sending device 110 and the receiving device 120.
- the sending device 110 may use an 8x8 binary permutation matrix R for the purposes of encoding data that carries P T , and the receiving device may use R T in its data decoding process for the purposes of recovering P T from the data encoded using R.
- one embodiment of a data protection method could include encrypting the data indicative of the default mapping prior to sending it to the receiving device, e.g., using a private key of a private key / public key pair, where the private key being uniquely known to the sending device, and where the public key is known by or made available to the receiving device.
- a central server 600 may securely communicate with the sending device 110 and/or the receiving device 120 in order to distribute the permutation matrix P during an initialization phase in signals 625 and 635.
- This secure communication may be implemented using current encryption technologies such as AES or DES, because it only requires the transmission of enough data to define a 2 N -by-2 N permutation matrix.
- the server 600 may communicate with each of the sending device 110 and the receiving device using the techniques taught herein with a pre-defined system size M and default encoding (and decoding) mapping that is a shared secret between the server 600 and the sending device 110, and between the server 600 and the receiving device 120 (it is noted that different shared secrets may be used by the server 600 when communicating with the sending device 100 and the receiving device 120 during the initialization phase).
- the central server 600 is equipped with a processor connected to a memory and an I/O, wherein the processor executes computer-readable instructions stored in the memory in order to perform the above specified functions.
- the sending device 110 and the receiving device 120 may each store a respective table 610 of pre-determined permutation matrices (Pi, P 2 , ... in the case of the sending device 110 and P T i, P T 2 , ... in the case of the receiving device 120) that is securely installed in the respective memory 114, 124, with each permutation matrix in the table being referred to by a unique code (1, 2, ... ).
- the sending device 110 may send a message 620 specifying the code corresponding to that permutation matrix in the table 610 2 stored in the memory 124 at the receiving device 120.
- This allows the transmission between the sending device 110 and the receiving device 120 to be unencrypted (i.e., plaintext) because the code corresponding to one of the permutation matrices in the memory 124 is meaningless to an outside observer that does not have the table 610 2 .
- This embodiment only requires the tables 610i and 610 2 to be securely populated beforehand.
- the sending device 110 and/or the receiving device 120 may choose to change the permutation matrix, or may be prompted to do so by an external party (e.g., a user, a central server). This can result the transmission of a new permutation matrix (appropriately protected or encrypted), or of a code corresponding to a new permutation matrix (which could be sent in plaintext).
- an external party e.g., a user, a central server
- the order in which the permutation matrix changes can be programmed such that the mere request for a change in the permutation matrix may prompt the sending device 110 and the receiving device 120 to navigate ("hop") through its respective table 610i, 610 2 of permutation matrices in a predefined way.
- the system size may be specified as an independent variable, and there may be different levels of sophistication, such as different tables of permutation matrices for different system sizes, such that a code may be valid when received for different system sizes but would refer to different permutation matrices of different sizes, but known / made available to both parties due to their prior storage in the table of permutation matrixes.
- both sides can agree to form a session permutation matrix by using the encoding/decoding mechanism described in this document.
- Using the newly formed permutation matrix for a session data transmission can improve the data transmission security.
- a change in session permutation matrix (which may involve a new system size) may be triggered by providing an indication to the sending device 110 and/or the receiving device 120.
- the indication may indicate a separation between N-bit input segments (and/or N-bit output segments) to be processed using the previous (old) permutation matrix and the N-bit input segments (and/or N-bit output segments) to be processed using the new permutation matrix.
- the indication may specify the number of bits (or segments) to which a first permutation matrix applies before a change of permutation matrix (which may involve a new system size) is required.
- the indication may signal an instantaneous change to a new system size or permutation matrix.
- the indication may signal a time at which the sending device or the receiving device is to switch over to a new system size or permutation matrix.
- the indication may provide a set of conditions which, when met, trigger a change in the permutation matrix, with the understanding that such conditions are being monitored by the sending and/or receiving devices 110, 120.
- An example of a condition is elapsed time, absolute time (e.g., change of day), number of bits processed, a detected hacking attempt, an interaction with a user through the I/O, etc.
- the indication may be controlled by the sending device 110 and transmitted from the sending device 110 to the receiving device 120, or it may be controlled by a server (e.g., central server 600) and send to both the sending device 110 and the receiving device 120.
- the indications may be encoded into a physical signal.
- all sending devices and receiving devices that are susceptible of communicating with one another are produced in the same secure facility 650.
- devices such as vehicles, satellites and smartphones that are produced in a secure plant.
- the vehicles, satellites, or smartphones can thus be provided with sending devices (110A, HOB, 1 IOC, respectively) embedded with the same encoding mapping P and with receiving devices (120A, 120B, 120C, respective) embedded with the same decoding mapping P T .
- Vehicle A, Vehicle B and Vehicle C can communicate amongst themselves (and/or with a central server at the secure facility 650 that is also aware of P and P ), and this communication remains secure once Vehicle A, Vehicle B and Vehicle C have left the plant 650 and entered the marketplace.
- Even in the case of a 12-bit system, the difficulty of hacking such a system is so extreme (as there are 2 12 factorial ((2 12 )! > 1E+13019) possible permutation matrices) that it is envisaged that a single encoding mapping would provide adequate data protection throughout the life of the vehicles, satellites, or smartphones.
- the mapping may therefore be securely embedded in the memory of each of the devices in such a way that it prevents any external access or tampering.
- the encoding mapping is locally generated based on an initial secret. This may follow the general process shown in Figure 10 and outlined below:
- Stage 1010 an initial secret S is shared between two peers (Alice and Bob).
- Stage 1020 Each of Alice and Bob locally generates an initial encoding mapping (e.g., permutation matrix P) based on the initial secret S.
- an initial encoding mapping e.g., permutation matrix P
- Figure 11 is similar to Figure 9 in that it shows two peers, Alice and Bob, communicating over the Internet 990.
- Alice implements a control module 980A and peer Bob includes a control module 980B.
- the control modules 980A, 980B are initialized and tuned so as to allow proper synchronization of the encoding mapping and decoding mapping being used by Alice and Bob.
- Alice has the ability to communicate with Bob not only over the Internet 990 but also over an alternate channel 1100.
- the alternate channel 1100 is an out-of-band (OOB) channel, which is out-of-band in that it does not utilize the Internet 990.
- OOB channel 1100 may be a cellular link established over the public switched telephone network (PSTN), or an NFC link.
- PSTN public switched telephone network
- Alice generates or obtains the initial secret S, which may but need not be a locally generated random number.
- Alice then generates a code 1230 (e.g., a QR code or hash code) from the identifier QID and the initial secret S.
- a code 1230 e.g., a QR code or hash code
- Alice sends a message 1240 containing the code 1230 to Bob over the alternate / out- of-band channel 1100.
- Bob then receives the message 1240 and decodes the initial secret S from the code 1230 based on Bob's prior knowledge of the identifier QID.
- Alice and Bob each have the initial secret S and can proceed to Stage 1020, which is described later on.
- Stage 1010 i.e., sharing of the initial secret S between Alice and Bob
- This embodiment does not use an out-of-band channel between Alice and Bob, but rather uses three parties to achieve the initial secret sharing, namely Alice, Bob, and a network element 1300 (e.g., a server).
- the server 1300 has the ability to communicate with both Alice and Bob over the Internet 990.
- the flow of operation is as follows:
- Both Alice and Bob send a respective hello message 1310 to the server 1300 before they start to talk to one another.
- the server 1300 replies with a respective reply message 1312 containing the server's public key PUK S to Alice and Bob. It is noted that the server's public key PUK S is part of a public/private key pair and that the server 1300 is therefore imputed to know its own private key PRK S ;
- the server 1300 decrypts the message 1320 with its private key PRK S and retrieves PUK_2 A and the token T, then records the token T, PUK_2 A , and Alice's IP address Alice-IP. It is noted that token T is stored in a memory in association with Alice's IP address Alice-IP. (2c) Alice then sends a message 1330 Sec-Req(T, PUK_1 A ) to Bob;
- Alice and Bob each have the initial secret S and can proceed to Stage 1020, which is described later on.
- Blockchains have generated interest in a variety of fields as a decentralized data storage mechanism with reliable redundant validation.
- An example application includes the exchange of cryptocurrencies (e.g., Bitcoins), which are transferred via transactions linked on a blockchain.
- Another example application includes the settlement of smart contracts, whereby rights and responsibilities of contracting parties are similarly transferred via transactions on a blockchain.
- a blockchain is used by Alice to share the initial secret S with Bob.
- a blockchain is a digital ledger in which transactions are recorded chronologically and publicly. From a technology point of view, and with reference to Figure 18, a blockchain 1800 is a continuously growing list of records, called blocks 1810, which are linked and secured using cryptography. A "block” is a container data structure and lists one or more transactions 1820.
- Participants to a transaction in a particular blockchain-enabled environment have an address, which is derivable from a participant's "public key” (e.g., by way of a hash function involving the public key and other information about the network).
- a participant's public key 1830 is known to other participants in the blockchain-enabled environment.
- the participant also has a private key 1840, which is used to sign transactions.
- the participant's public key 1830 is used by such other participants to verify the signature of a received transaction.
- An algorithm such as elliptic curve cryptography, can be used to generate one or more public keys from the private key.
- such algorithm may involve converting the private key to a binary representation, identifying the bits in this binary representation that have a value of 1, and summing an exponentially multiplied generator variable to arrive at the final public key. While the process of public key generation is quite straightforward, reversing the process is computationally intense.
- the private key 1840 and the public key 1830 can be large integer numbers, but since these numbers can be very large, they tend to be represented using a separate format consisting of letters and numbers (e.g., Wallet Import Format (WIF)).
- WIF Wallet Import Format
- the private key and the one or more public keys may be stored by a "wallet”.
- a wallet 1850 can be a software client of the blockchain-enabled environment that is associated with a given participant.
- the wallet 1850 can be implemented as computer-readable instructions carried out by a processor in a mobile phone or desktop computer, for example.
- the wallet 1850 may be configured to allow the participant to receive and send blocks in which transactions are listed.
- a transaction 1820 includes the sender's address 1910, a recipient's address 1920, transaction content 1930 and a signature 1940.
- the transaction content 1930 and the participant's private key 1840 are used to generate the signature 1940.
- a hash message authentication code (HMAC) can also be generated and inserted in the transaction 1820 to allow authenticity of the transaction content 1930 to be verified.
- the transaction content 1930 is an encrypted version of the initial secret S.
- Alice's control module 980A first uses Alice's private key PRK A plus Bob's public key PUK B to generate a shared key K s .
- the shared key K s has the special property of being derivable from both the combination of Alice's private key PRK A key plus Bob's public key PUK B , and from the combination of Alice's public key PUK A key plus Bob's private key PRK B .
- Control module 980A uses the shared key K s to encrypt the initial secret S (resulting in a "shared secret" SS) and creates a transaction on the blockchain.
- the transaction is from Alice and destined for Bob.
- Bob's control module 980B uses Bob's private key PRK B plus Alice's public key PUK A to generate the same shared key K s .
- Bob then uses this shared key K s to decrypt the initial secret S from the shared secret SS.
- Alice and Bob each have the initial secret S and can proceed to Stage 1020, which is described herein below.
- the initial secret S should have a certain minimum length.
- the size of the initial secret S can be based on the system size N, and may correspond to N * 2 N bits.
- this is not to be viewed as a limitation, as other lengths can be used.
- each of Alice and Bob locally generates an initial encoding mapping (e.g., permutation matrix P) based on the initial secret S known to both parties.
- an initial encoding mapping e.g., permutation matrix P
- the control modules 980A, 980B are configured to generate the permutation matrix P (as well as its transpose P T ), by executing a process referred to as "EntroGen(*)" whose argument is, in this case, the initial secret S.
- the EntroGen(*) process implements an algorithm 1410 for generating P and P T , which can take on many forms, such as an array shuffle algorithm, including the Key Scheduling Algorithm (KSA), Fisher- Yates Shuffle, etc., with information states from 0 to (2 N -1).
- KSA Key Scheduling Algorithm
- 2 N -by-2 N permutation matrix P can be expressed by a "states array" S[2 N ].
- the EntroGen(*) process involves passing the initial secret S through a hash module 1420 in order to generate an intermediate secret S*, which is then processed by the appropriate (e.g., array shuffle) algorithm 1410.
- the hash module 1420 ensures that a small difference in S would produce a vastly different permutation matrix P.
- each of Alice and Bob maintains an "Entropy History Table” 3310, 3320 in the respective memory.
- the Entropy History Table keeps track of recently configured entropy "records".
- Each such entropy record includes a plurality of entries, including an ID of the peer associated with the record (under the "App ID” column, noting that this is not the identity of the peer where the Entropy History Table is stored, but rather the identity of another peer with which such peer communicates), a time indicator (e.g., time stamp or time frame or sequence number, under the "time” column), an entropy state (under the "QE” column) and a hash (under the "Hash” column).
- an ID of the peer associated with the record under the "App ID” column, noting that this is not the identity of the peer where the Entropy History Table is stored, but rather the identity of another peer with which such peer communicates
- a time indicator e.g., time stamp or time frame or sequence number, under the "time” column
- a given entropy state is uniquely associated with an encoding mapping / permutation matrix.
- each entropy record is associated with a time frame or sequence value, it becomes possible to readily find a previous entropy state and configure the associated permutation matrix; this can be done by both Alice and Bob independently, if provided with of the same time indicator.
- the entropy state associated with one time indicator is dependent on the entropy state associated with a previous time indicator.
- the hash is produced by passing the entropy state through a hash function, which may be a one-way function.
- the first phase is a preliminary phase.
- the second phase is an update phase.
- the preliminary phase is now described with reference to Fig. 33B and steps 3310 through 3370.
- Step 3310 Alice generates a public-private key pair. Alice's public key is denoted PUK A .
- Step 3320 Alice sends Bob a message comprising Alice's public key PUK A . This information may reach Bob via a third party, i.e., not necessarily directly sent to Bob by Alice.
- the initial entropy state E 0 may be represented by a states array S 0 [2 N ].
- Step 3340 Bob sends PU(E 0 ), the encrypted version of the initial entropy state E 0 , to Alice's ID.
- Step 3350 Alice decrypts the initial entropy state E 0 using the private key, which is known to
- Step 3360 Alice and Bob produce the hash H 0 and update their Entropy History Table with H 0 and Eo for the current time indicator to.
- Step 3370 Alice and/or Bob set a trigger to trigger the update phase at a later time, possibly a random time in the future.
- the trigger may be implemented as a timer.
- Step 3402 One of the triggers is set off. This could be Alice's trigger or Bob's trigger. Let it be assumed, for the purposes of the present discussion, that it is Alice's trigger that is received (e.g., a timer that expires first). This means that it is time to determine the entropy state for a new time indicator ti (denoted Ei) and the corresponding hash (to be denoted Hi).
- Step 3404 Alice obtains the initial entropy state E 0 and the hash H 0 for the current time indicator to-
- Step 3406 Alice obtains the encoding mapping P (and P T ) uniquely associated with the entropy state Eo.
- Step 3408 Alice requests a random number, denoted g.
- Step 3410 Alice creates a new entropy state Ei from g and the current entropy state, which is the initial entropy state E 0 .
- this is merely an example and should not be viewed as a limitation, as many other operations are possible.
- Step 3412 Alice generates hash Hi from the new entropy state Ei using a desired technique.
- Step 3414 Alice updates its Entropy History Table with the new entropy state E 0 and the associated hash H 0 and for the new time indicator ti .
- Step 3416 Alice computes or otherwise obtains the quantropized version of g, namely P(g).
- Step 3418 Alice sends the hash H 0 and P(g) to Bob. It is noted that g is quantropized and therefore P(g) can be sent in plaintext, although it is also feasible to encrypt it.
- Step 3420 Bob receives the hash H 0 and P(g). Based on the hash H 0 , Bob consults the Entropy
- Step 3422 Bob obtains the encoding mapping P (and P ) associated with entropy state E 0 obtained at step 3420.
- Step 3424 Bob applies the decoding mapping P T to P(g). It is only in the case where Bob has the same Entropy History Table as Alice that this operation will give g. That is to say, if Bob does not have the same Entropy History Table, Bob may not find a match to the hash H 0 , or if a match is somehow found, it will not correspond to entropy state E 0 , which means that the result of Step 3422 will not result in P T , but rather a different mapping that will not allow g to be extracted.
- this is merely an example and should not be viewed as a limitation, as many other types of operations are possible.
- Step 3428 Bob generates the hash Hi from the new entropy state Ei using a desired technique.
- Step 3430 Bob sends the hash Hi and Bob's ID to Alice.
- Step 3432 Alice receives the hash Hi and recognizes Bob's ID and sees that Bob sent the expected hash Hi for time indicator ti.
- Another method to update the entropy the Entropy History Tables would be, after initial synchronization, to use the most recent entropy state (e.g., E x ) as a symmetric cryptographic key that encrypts the new entropy state (e.g., E x +i).
- each entropy state depends on the previous entropy state, which depends on the one before that.
- a chain of entropy states is created, and each such entropy state E x defines an encoding mapping P x .
- each peer will know which entropy state, and therefore which encoding mapping, to use.
- FIGS. 17A-17C conceptually illustrate various possible implementation scenarios related to the foregoing.
- Alice is equipped with a quantropization module 982A that includes the necessary functional modules related to quantropization (and dequantropization), as previously discussed.
- Bob is equipped with quantropization module 982B that includes the necessary functional modules related to dequantropization (and quantropization). It is assumed that Alice and Bob have reached agreement as to which encoding and decoding mapping to use; this can be achieved according to any of the aforementioned initialization methods (including maintaining an Entropy History Table and agreeing on the current time indicator). Also, optionally, Alice may be equipped with an application module 981 A and Bob may be equipped with an application module 98 IB. The application modules 981 A and 98 IB communicate "application data" such as a message between two users.
- Alice's application module 981 A communicates application data with Bob's application module 98 IB using, e.g., a conventional encryption scheme.
- An example of such an encryption scheme can be the Advanced Encryption Standard (AES), which may be considered secure if a sufficiently long encryption key is used; however, the issue becomes how to make Alice and Bob aware of the same encryption key without exposing this encryption key to a security risk.
- AES Advanced Encryption Standard
- Alice's application module 981A determines the desired encryption key, invokes Alice's quantropization module 982A at step 1702.
- the quantropization module 982A applies the encoding mapping to the encryption key to produce a quantropized key and returns it to the application module 981A at step 1704.
- Alice's application module 981A then sends the quantropized key to Bob's application module 981B over the network 990.
- Bob's application module 981B then invokes Bob's quantropization module 982B with the quantropized key (step 1706), which dequantropizes the quantropized key (using the decoding mapping) so as to obtain the original encryption key and returns it to the application module 98 IB (step 1708).
- the application modules 981A and 98 IB can use the encryption key (which has been securely transmitted from Alice to Bob) to encrypt application data using AES, TLS (Transport Layer Security), SSL (Secure Sockets Layer) or any other suitable cryptographic protocol. While this description has dealt with a key being sent from Alice to Bob, the opposite could be true as well.
- Second implementation scenario encoding mapping used by Alice to encode application data for transmission to Bob
- Alice's application module 981 A sends application data to Alice's quantropization module 982 A (step 1712).
- Alice's quantropization module 982 A quantropizes the application data (using the encoding mapping) and returns quantropized data back to Alice's application module 981A (step 1714), which sends the quantropized data to Bob's application module 98 IB over the network 990.
- Bob's application module 98 IB sends it to Bob's quantropization module 982B for dequantropization (step 1716).
- Quantropization module 982B dequantropizes the application data (using the decoding mapping) and returns the original data to Bob's application module 98 IB (step 1718), where it is interpreted and processed.
- Alice's quantropization module 982A could send the quantropized application data directly to Bob's quantropization module 982B over the network 990.
- Alice's application module 981A communicates application data with Bob's application module 98 IB using, e.g., a conventional encryption scheme.
- An example of such an encryption scheme can be the Advanced Encryption Standard (AES), which may be considered secure if a sufficiently long encryption key is used; however, the issue becomes how to make Alice and Bob aware of the same encryption key without exposing this encryption key to a security risk.
- AES Advanced Encryption Standard
- the encryption key is not transmitted from Alice to Bob. Rather, Alice and Bob locally generate the encryption key based on the encoding mapping (e.g., permutation matrix P) of which they are both aware.
- the encoding mapping e.g., permutation matrix P
- Stage 1030 Each of Alice and Bob obtains a common seed from a seed source.
- the seed may be a randomly generated quantity.
- Stage 1040 Each of Alice and Bob creates an encryption key using the encoding mapping (e.g., permutation matrix P) and the seed.
- encoding mapping e.g., permutation matrix P
- Stage 1050 Alice and Bob are now ready to encrypt their communications using the encryption key.
- the aforementioned stages are now described in the context of two possible variants, having regard to Figures 15 and 16. Shown in both of these figures is the server 1300, which may have the ability to generate random numbers and to communicate with both Alice and Bob over the Internet 990.
- the first variant shown in Figure 15, is referred to as the request-response variant. It is assumed that Bob wants to establish communication with Alice.
- the flow of operation is as follows (it is understood that control modules 980A and 980B within Alice and Bob are configured to carry out these actions):
- Bob sends a message 1510 requesting a seed from the server 1300.
- the message 1510 specifies Alice's client identifier (denoted QID), Alice's IP address (denoted Alice-IP), and other information such as a number of bytes.
- the server 1300 generates a seed (denoted SEED).
- the seed SEED may be generated by a truly random quantum process at the server 1300.
- the server 1300 records Alice's client identifier QID and Alice's IP address Alice-IP in association with the seed SEED.
- the server 1300 responds to Bob with a message 1520 containing the seed SEED for communicating with Alice.
- Bob receives the message 1520 containing the seed SEED and implements a key generation process to generate an encryption key (denoted QK) using, as inputs, the seed SEED and the permutation matrix P (which was obtained previously).
- the seed SEED can be treated as an information input of a matrix multiplication with the permutation matrix P.
- the output will then be the encryption key QK. Due to the feature of randomness of the seed SEED, so the resulting encryption key QK is also random.
- the message 1530 specifies Alice's client identifier QID, Alice's IP address Alice-IP, and other information such as a number of bytes.
- the server 1300 consults its records (e.g., in memory) and verifies whether Alice's IP address Alice-IP matches the address that Bob had indicated (in message 1510) should be associated with Alice's identifier QID for this session. If there is a match, the server 1300 responds with a message 1540 containing the previously generated seed SEED; if there is no match, the server 1300 may respond with a warning message (not shown) and/or Alice's request is rejected.
- its records e.g., in memory
- the server 1300 responds with a message 1540 containing the previously generated seed SEED; if there is no match, the server 1300 may respond with a warning message (not shown) and/or Alice's request is rejected.
- Alice receives the message 1540 containing the seed SEED and generates the same encryption key QK as was generated by Bob, using, as inputs to the key generation process, the seed SEED and the permutation matrix P. At this point, Alice and Bob have possession of the encryption key QK.
- This process of transforming a seed (such as SEED) into an encryption key (such as QK) using a permutation matrix (such as P) can be repeated on-demand during the course of secure communications.
- the messages 1520 and 1540 containing the seed SEED do not need to be transmitted with utmost security (e.g., they can even be transmitted in plaintext), which reduces the complexity of key distribution.
- utmost security e.g., they can even be transmitted in plaintext
- this does not allow the third party to obtain the encryption key QK. This makes distribution of the encryption key QK feasible and secure for today's internet needs, while avoiding the physical constraints of traditional quantum key distribution.
- the second variant of Stages 1030-1050, shown in Figure 16, is referred to as a "broadcast" variant.
- the server 1300 may be a broadcast server for true quantum random seeds.
- the flow of operation is as follows:
- the server 1300 issues broadcast messages 1630 containing seeds SEED1, SEED2, etc.
- An example format of a message containing a seed may be: 4 bytes of seedID / timestamp, IK bytes of seed, in addition to a signature so a receiver can verify the integrity of the seed. Other formats are of course possible.
- Alice and Bob each receive various ones of the broadcast messages 1620, and store the seeds SEED1, SEED2, etc. contained in such messages.
- Alice and Bob each generate the encryption key QK using, as inputs to the key generation process, the agreed-upon seed and the permutation matrix P or its transpose.
- Stages 1030-1050 by way of either the first or second variant, for example), Alice and Bob have possession of the encryption key QK.
- This key cannot be easily determined by a malicious third party, even if the seed used to generate the encryption key QK is intercepted. This is because the encryption key QK is generated using the permutation matrix P (or its transpose P T ).
- the distribution of the encryption key QK may thus be considered secure, and if the encryption key QK is sufficiently long, one can now proceed to transmit data using AES (with the encryption key QK) while retaining a high level of security.
- a non-limiting example use case of the present technology is to enable of secure communication over the internet (e.g., amongst smartphones, automatic teller machines, corporate servers, data centers, satellites, e-commerce servers, vehicles, IoT devices including smart home appliances, etc.).
- internet e.g., amongst smartphones, automatic teller machines, corporate servers, data centers, satellites, e-commerce servers, vehicles, IoT devices including smart home appliances, etc.
- Embodiments of the invention can be applied to any layer of communication, such as any layer of the OSI (open systems interconnect) reference model because it deals with primitive data N- bit segments.
- the near end device takes an input bit stream and applies the encoding mapping (e.g., permutation matrix P) to N-bit segments to produce an output bit stream of N-bit segments, finally modulating the output bit stream before sending it to the far end device over the channel 130; and upon receipt, the far end device performs the decoding process by applying the decoding mapping (e.g., permutation matrix P T ) to obtain back the original bit stream.
- This physical layer implementation can be applied to long haul/metro point-to-point transmissions for highly secure data communications.
- the encoding process may be executed by a sending application and the decoding process may be executed in a receiving application.
- the sending application may share the permutation matrix P with the receiving application, and when the sending application plans to send data, it performs the permutation switching with the given segment size N and then the output bit segments will be converted into a regular bit stream or byte stream to send; at the receiving application, it will apply permutation switching with P T to bring back the original data.
- P T permutation switching with P T to bring back the original data.
- Embodiments of the invention can be also implemented as software-only such as in applications directly, or a software-embedded system such as inside a network protocol stack, to be enabled and disabled, as well as browser adds-on, etc. Certain embodiments can also be implemented in data communication devices such as network nodes, routers/wireless and wireless base stations. As well, certain embodiments can be implemented into smart phone transmission/receiving units, or mobile applications. Data security for internet information communications may thus be improved.
- V2V vehicle-to-vehicle
- Certain embodiments can be used to build a secure space for cloud data storage by providing an integrated encoding and decoding device in the front of cloud data storage devices. All data would be encoded by the device using the permutation matrix P before sending to storage devices and decoded by the device using the same permutation matrix P T before sending out of the cloud.
- V2V private network Enable secure communication amongst vehicles on the road (V2V private network).
- a further non-limiting example use case pertains to an individualized operating system (OS) obtained by embedding a permutation switching sublayer into the OS to enhance data security and prevent data breaches.
- the permutation switching sublayer utilizes a permutation switching matrix as described above.
- the permutation switching matrix can be automatically determined by each individual system, based on system identifiers. In doing so, malicious software cannot be run in such an individualized system.
- Fig. 7A illustrates a typical process for an OS to load an application into memory then run it.
- malware might execute in a computing system if the malware is in the system; this type of occurrence gives the malware a "write once and run everywhere" attribute which can create huge damage to users.
- an individualized OS consists of the typical OS with embedded application localizer (Fig. 7B) and embedded application loader (Fig. 7C).
- the typical OS generate the installed system permutation matrix based on the OS license and the hardware system characteristics, securely stored into its system or re-produced at run-time it every time when the system starts.
- a user application must be "localized", with the user authorization, by the embedded application localizer with a permutation switching (using the permutation matrix P) to application executables and generating localization IDs stored into the localized application images.
- IoT Internet of Things
- the IoT environment 2200 generally refers to an ensemble of IoT-enabled objects 2210, typically with some data reporting or control functionality, that are in communication with an application device 2220 over a network such as the Internet 990.
- IoT-enabled objects 2210 can include physical devices such as smart home appliances (washers, dryers, vacuums, ovens, refrigerators, thermostats, cameras, etc.), clothing, toys, healthcare devices, vehicle parts and various other items embedded with electronics, sensors (optional), software and a network communication interface.
- the application device 2220 is interested in sending messages to, and receiving messages from, the various IoT-enabled objects 2210. Examples of the application device 2220 could be a smartphone, workstation, laptop or mainframe server.
- the IoT environment 2200 may include further interconnected network elements 2270, 2280 having various other functionalities.
- a computer-implemented method of synchronizing an Internet-enabled object 2210 (or Internet-enabled appliance) with the application device 2220 may be implemented in this environment. Such a method could include a portion carried out at the application device 2220 and a portion carried out at the Internet-enabled appliance.
- the application device 2220 may generate an encoding mapping based on (i) a previous encoding mapping used to communicate previously with the appliance 2210 and (ii) a seed (e.g., from a remote server over the Internet); and transmit the encoding mapping to the appliance 2210 over a local connection that does not traverse the Internet.
- the appliance 2220 upon receiving the encoding mapping over the local connection, may use the encoding mapping to subsequently secure data exchanged with the application device 2220 over the Internet.
- the application device 2220 may also receive encoded data from the appliance 2210 and decode the data using a decoding mapping derivable from the encoding mapping.
- the appliance 2300 may be conventional in many respects except that it also includes a microprocessor-enabled IoT communication device 2310.
- the IoT communication device 2310 includes a processor 2312, a memory 2314 and a network communication interface 2316.
- An external sensor 2318 may also be provided, or the sensor 2318 may be embedded elsewhere in the appliance 2300 with the output of the 2318 sensor being supplied to the IoT communication device 2310.
- the IoT communication device 2310 may be powered from the same power source as the rest of the appliance 2300, or it may include its own power source (e.g., a battery).
- the IoT communication device 2310 may also include other components that are not specifically illustrated.
- the memory 2314 stores computer-readable instructions that are executed by the processor 2312.
- the computer-readable instructions have a small code footprint, sometimes as small as 30 kilobytes (30KB), so as to facilitate usage with battery-powered appliances.
- the processor 2312 can carry out a variety of processes, including a communications process 2320, a data security process 2330, a sensing process 2340 (which is optional) and data processing process 2350.
- the aforementioned functions may be implemented by the existing hardware and software of the appliance 2300, i.e., in the absence of a dedicated microprocessor-enabled IoT communication device. Additional processes may be encoded in the computer-readable instructions stored in the memory 2314 and executable by the processor 2312.
- the application device 2220 does not require a dedicated microprocessor- enabled IoT communication device, as existing hardware and software of the application device 2220 can be utilized to provide the requisite functionality.
- the application device 2220 includes, inter alia, a processor 2812, a memory 2814, a network communication interface 2816 and a user interface 2818 (which can include various input/output devices such as a screen, keyboard, loudspeaker, etc.).
- the memory 2814 stores computer-readable instructions that are executed by the processor 2812. Execution of the computer-readable instructions may cause the processor 2812 to carry out an operating system 2880 and various applications (or "apps") 2882. One such app may exhibit functionality for monitoring and/or controlling the appliance 2300. To this end, carrying out the app may involve executing a variety of processes, including a communications process 2820, a data security process 2830, a data processing process 2850 and a user interface process 2860. Additional processes and apps may be encoded in the computer-readable instructions stored in the memory 2814 and executable by the processor 2812.
- the sensing process 2340 may include steps of obtaining a reading from the sensor 2318 and storing the reading in the memory 2314. Readings from the sensor 2318 may be obtained at regular intervals or on demand upon receipt of a command. Examples of the sensor 2318 include a thermometer, an inclinometer, a light sensor, a hygrometer, a carbon monoxide sensor, an accelerometer, a pressure sensor, an image sensor (e.g., CCD) and a detection and ranging sensor (radar, lidar, sonar), to name a few non-limiting possibilities.
- a thermometer e.g., an inclinometer, a light sensor, a hygrometer, a carbon monoxide sensor, an accelerometer, a pressure sensor, an image sensor (e.g., CCD) and a detection and ranging sensor (radar, lidar, sonar), to name a few non-limiting possibilities.
- the data processing process 2350 (executed by the processor 2312 of the IoT communication device 2310 of the appliance 2300) may include a step of processing the sensor data in the memory 2314 in order to produce consumable data for transmission to an external party.
- the consumable data may take the form of a stream of bytes in a certain format demanded by the external party.
- the sensing process 2340 may produce and store a temperature reading once every 5 minutes and the data processing process 2350 may determine an average temperature over 1 hour by averaging the 12 most recent entries stored in the memory 2314.
- the user interface process 2860 (executed by the processor 2812 of the application device 2220) may include a step of interacting with a user of the application device 2220 so as to obtain an indication of a request from the user. For example, the user may request a reading from a remote appliance (such as the appliance 2300) or the user may request to exert control of such appliance.
- the user interface process 2860 may also include a step of presenting information to the user in a particular format, such as graphically.
- the data processing process 2850 (executed by the processor 2812 of the application device 2220) may include a step of processing various data before displaying it via the user interface 2818.
- the data processing process 2850 may thus perform various manipulations on the data in the memory 2814, including graphical and mathematical manipulations.
- this process implements certain media access control (MAC) and physical (PHY) specifications for communicating with a nearby network access point 2360 via the network communication interface 2316.
- MAC media access control
- PHY physical
- network connectivity may be achieved wirelessly with a home router over Wi-Fi.
- Other low-level protocols for communication between the appliance 2300 and the nearby access point 2360 include Bluetooth, near-field communication (NFC) and Zigbee, to name a few non-limiting possibilities.
- the home router 2360 which is typically connected to a service provider modem (not shown), then provides the IoT communication device 2310 with access to the Internet.
- the communication process 2820 (executed by the processor 2812 of the application device 2220) may also implement certain media access control (MAC) and physical (PHY) specifications for communicating with a nearby network access point 2360 via the network communication interface 2316.
- MAC media access control
- PHY physical
- this type of low-level communication for providing a data connection to the Internet may instead be handled by the operating system of the application device 2220.
- Such low-level communication may be conventional, and thus it will not be described here.
- both the communication process 2320 and the communication process 2820 also implement certain higher-layer protocols for communicating with entities on the Internet.
- a non-limiting example of such a higher-layer protocol is MQTT (Message Queuing Telemetry Transport), which works on top of the TCP/IP protocol. Further details about the MQTT protocol can be found at www.mqtt.org, the contents of which are incorporated by reference.
- MQTT Message Queuing Telemetry Transport
- Other non-limiting examples of a higher-layer protocol for communicating with the server over the Internet include Advanced Message Queuing Protocol (AMQP), Streaming Text Oriented Messaging Protocol (STOMP), IETF Constrained Application Protocol, XMPP, DDS, OPC UA, and Web Application Messaging Protocol (WAMP).
- AMQP Advanced Message Queuing Protocol
- STOMP Streaming Text Oriented Messaging Protocol
- WAMP Web Application Messaging Protocol
- the MQTT protocol follows a publish/subscribe messaging model. Instead of the traditional client-server model, where a client communicates directly with the server, the publish/subscribe model provides for two types of "client" participants that communicate messages through a broker. Each message is ascribed a "topic". Each client can be a "publisher” client for certain topics and/or a "subscriber” client for certain other topics.
- the publisher clients are decoupled from the subscriber clients by the broker, which is known by both the publisher and subscriber clients (e.g., at a predetermined URL).
- the broker filters all incoming messages and distributes them according to topics.
- the broker is considered the heart of any publish/subscribe messaging model such as is implemented by the MQTT protocol. Depending on the concrete implementation, the broker can handle up to thousands of concurrently connected IoT-enabled objects.
- the broker is primarily responsible for receiving all messages, filtering them according to topic, determining who is interested in which topics and then sending the filtered messages to all subscribed clients.
- the broker also holds the session of all persisted clients including subscriptions and missed messages.
- the IoT-enabled objects 2210 and the application device 2220 can be considered the MQTT clients.
- the appliance 2300 can be a publisher client of certain topics and a subscriber client to others.
- the application device 2220 can be a publisher client of certain topics (including those topics to which the appliance 2300 subscribes) and can be a subscriber client to certain other topics (including those topics published by the appliance 2300).
- One of the network elements, in this case network element 2280, can play the role of the MQTT broker.
- the MQTT broker 2280 can be implemented as a server on the Internet having a pre-determined IP address.
- Each of the MQTT clients 2220, 2300 runs a suitable MQTT protocol library and connects to the MQTT broker 2280 over a suitable network connection.
- the MQTT protocol is based on top of TCP/IP and therefore the MQTT clients 2220, 2300 and the MQTT broker 2280 each implement a TCP/IP stack.
- An MQTT connection itself is always between one MQTT client and the MQTT broker 2280; no MQTT client is connected to another MQTT client directly.
- the connection is initiated through an MQTT client sending a CONNECT message to the MQTT broker 2280.
- the MQTT broker 2280 responds with a CONNACK message and a status code. Once the connection is established, the MQTT broker 2280 will keep it open as long as the client does not send a DISCONNECT command or the connection is otherwise lost.
- an MQTT client After an MQTT client is connected to the MQTT broker 2280, it can publish messages.
- the MQTT protocol implements topic-based filtering of the messages by the broker, so each message must contain a topic, which will be used by the MQTT broker 2280 to forward the message to interested MQTT clients.
- a PUBLISH message can include the name of a topic and a payload.
- a SUBSCRIBE message includes the name of a topic.
- the MQTT broker 2280 notes which MQTT clients have subscribed to which topics. Thus, when the broker receives a PUBLISH message from an MQTT client for a particular topic, the MQTT broker 2280 routes the PUBLISH message to those MQTT clients that have subscribed to the particular topic.
- Figure 24 shows an example of the subscription, publishing and brokering concepts of the MQTT protocol, applied to the IoT environment of Fig. 21, and carried out by the communication process of each respective IoT-enabled object (in the case of the appliance 2300, this is the communication process 2320 and in the case of the application device 2220, this is the communication process 2820).
- the appliance 2300 may be configured to capture sensed data (e.g., via the sensing process 2340) and may have the capability of publishing messages containing this sensed data under topic "X".
- the broker 2280 registers the application device 2220's interest in topic X.
- MQTT message 2500 in this case a PUBLISH message.
- all MQTT messages include a fixed header field 2510 with a control header field 2512 and a packet length field 2514.
- the control header field 2512 indicates the type of MQTT message (in this case a PUBLISH message).
- the packet length field 2514 indicates the length of the MQTT message 2500.
- Such fields do exist for a PUBLISH message, but their length and content varies.
- the header field 2520 includes a topic name length field 2522, a topic name field 2524 and a message ID field 2526 (also referred to as a time stamp).
- the topic name length field 2524 indicates the topic to which the PUBLISH message 2500 relates, while the topic name length field 2522 indicates the length of the topic name length field 2522.
- the message ID field 2526 this may indicate a sequential number issued by the source of the message 2500, which could be unique for each message or unique for each message having the same topic.
- the payload field 2530 contains the application message to be published.
- the MQTT protocol is data-agnostic, and how the payload is structured depends on the use case. It is completely up to the sender if it wants to send binary data, textual data or even full-fledged XML or JSON.
- IoT-enabled objects suffer from security issues similar to those of conventional servers, workstations and smartphones, except that firewall, security update and anti- malware systems used for the latter types of devices are generally unsuitable for the typically smaller, less capable, IoT-enabled objects.
- a solution is to provide the IoT-enabled objects with data security processes, as now described in greater detail.
- the data security processes 2330, 2380 function as a layer above the respective communication process 2320, 2820.
- the communication processes 2320, 2820 are responsible for functionality such as modulation and demodulation, antenna / gain control and connection maintenance (e.g., retransmissions at the TCP level).
- the data security process 2330, 2830 are responsible for the following three functions:
- Function 1 Determining and distributing the encoding and decoding mappings
- Function 2 Quantropization and dequantropization using the encoding and decoding mappings
- Function 3 Remote tuning of the encoding and decoding mappings.
- each of these devices needs to know the encoding mapping that it will use to quantropize its data, and vice versa using a decoding mapping.
- the data security process 2330 carried out by the appliance 2300 and the data security process 2830 carried out by the application device 2220 are responsible for determining the encoding and decoding mappings and coordinating their distribution.
- the data security process 2830 of the application device 2220 is responsible for determining the permutation matrix P of dimensionality 2 N by 2 N and distributing it to the data security process 2330 of the appliance 2300.
- the processor 2812 of the application device 2220 may handle a greater computational load than the processor 2312 of the appliance 2300.
- FIG. 27 further illustrates one of the IoT-enabled clients in the IoT environment 2200, in this case network element 2270, having the role of a "seed distributor".
- the seed distributor 2270 may be configured to generate seeds using a random process as is known in the industry.
- the data security process 2830 of the application device 2220 obtains an initial seed ISEED.
- the initial seed ISEED may have been stored in the memory 2814 of the application device 2220.
- the data security process 2830 of the application device 2220 generates an encoding mapping based on the initial seed ISEED.
- the data security process 2830 may execute the EntroGen(*) process. It is recalled that EntroGen(*)process produces an encoding mapping based on the value of the argument. Thus, for example, calling EntroGen(ISEED) produces an initial permutation matrix Pi.
- the seed distributor 2270 generates a random seed QSEED. This may be a true random number in the mathematical sense, but this is not a requirement. It may simply be a bit string of any particular size that would be difficult for an outside party to guess.
- the seed distributor 2270 sends the random seed QSEED to the application device 2220 via the broker 2280. That is to say, the seed distributor 2270 places the random seed QSEED into the payload of a PUBLISH message 2735, for which the topic is chosen to be "SEED" (by way of example). Meanwhile, the application device 2220 is assumed to subscribe to the topic "SEED". The PUBLISH message 2735 reaches the broker 2280, which recognizes that the application device 2220 subscribes to the topic "SEED” and accordingly routes the PUBLISH message 2735 to the application device 2220. The version of the PUBLISH message 2735 routed by the broker 2280 is given the reference numeral 2735* in order to distinguish it from the PUBLISH message 2735 received by the broker 2280, since there will be processing by the broker 2280.
- the PUBLISH message 2735 transmitted by the seed distributor 2270 towards the application device 2220 via the broker 2280.
- the PUBLISH message 2735 has structural elements corresponding to those previously described with respect to the message 2500, namely a fixed header field 3010, a header field 3020 (containing the topic name "SEED") and a payload field 3030.
- the topic "SEED" signals transmission of the random seed QSEED within the payload field 3030.
- the payload field 3030 may also include a seed ID (which is an identifier of the seed being published), a hash-based message authentication code (HMAC, which is optional) and a time stamp (which can be measured in terms of relative packet order or in terms of elapsed time, for example).
- a seed ID which is an identifier of the seed being published
- HMAC hash-based message authentication code
- a time stamp which can be measured in terms of relative packet order or in terms of elapsed time, for example).
- the PUBLISH message 2735 ultimately reaches the application device 2220, where and the contents of the payload field 3030 of the PUBLISH message 2735 is extracted by the communication process 2820. In short, this is how the data security process 2830 of the application device 2220 obtains the random seed QSEED.
- the data security process 2830 generates a key QK by applying the initial permutation matrix Pi to the received random seed QSEED. Then, the data security process 2830 calls the EntroGen(*) process again, but with the key QK as the argument. This results in the permutation matrix P. It is noted that by applying the initial permutation matrix Pi to the received random seed QSEED before calling EntroGen(*), even if an outsider knows the EntroGen(*) process and the random seed QSEED, they still cannot generate the permutation matrix P.
- the application device 2220 carries out the process of distributing the permutation matrix P to the IoT-enabled devices with which it is wants to securely communicate.
- this includes the appliance 2300.
- the application device 2220 establishes a link 2770 with the appliance 2300 over a secure private network, such as local private WiFi, NFC or Bluetooth.
- a secure private network such as local private WiFi, NFC or Bluetooth.
- Step 2760 can be carried out whenever the application device 2220 wishes to perform a reset or re-synchronization of the encoding mapping with the appliance 2300 or other IoT-enabled devices with which it communicates. Re-synchronization can be motivated by a variety of factors, such as the passage of a certain amount of time or a perceived security breach. It is noted that the seed distributor 2270 may publish random seeds on a regular basis (e.g., as PUBLISH messages under the topic "SEED"), and the application device 2220, in subscribing to the topic "SEED", may receive these seeds (via the broker 2280) and use them for resynchronization purposes as required.
- PUBLISH messages under the topic "SEED”
- a PUBLISH message 2600 transmitted by the appliance 2300 towards the application device 2220 via the broker 2280.
- the message 2600 has structural elements corresponding to those previously described with respect to the message 2500, namely a fixed header field 2610, a header field 2620 (containing the topic name) and a payload field 2630.
- the topic "QEP" stands for "Quantum Entropy Processing" signals transmission of a quantropized bit string in the payload field 2630.
- the quantropized bit string corresponds to a bit string carrying sensor data or any other kind of information provided by the data processing process 2350, and having undergone quantropization.
- the corresponding bits in the information space may include additional information such as a seed ID (e.g., an identifier of the seed from which the current version of the encoding mapping was generated), a hash-based message authentication code and a time stamp (which can be measured in terms of relative packet order or in terms of elapsed time, for example).
- a seed ID e.g., an identifier of the seed from which the current version of the encoding mapping was generated
- a hash-based message authentication code e.g., a time stamp (which can be measured in terms of relative packet order or in terms of elapsed time, for example).
- all this information can be concatenated and quantropized before being placed into the payload field 2630 of the PUBLISH message 2600.
- this information e.g., the sensor data, the seed ID
- is quantropized and then is concatenated with other (non-quantropized) information e.g., HMAC and time stamp
- Quantropization is achieved by the data security process 2330 of the appliance 2300 applying an encoding mapping that is stored in the memory 2314.
- the encoding mapping is represented by a permutation matrix P of dimensionality 2 N by 2 N
- the decoding mapping is represented by the matrix P T .
- the decoding mapping is assumed to be also known to the application device 2220 (see Function 1), which is further assumed to subscribe to the topic "QEP" and is tasked with carrying out the corresponding dequantropization process to retrieve the sensor data or other information.
- the data security process 2330 of the appliance 2300 includes a step of breaking down (disassembling) an input bit string 2650 received from the data processing process 2350 into N-bit segments which are mapped to corresponding N-bit output segments. Specifically, for each given N-bit segment in the input bit string, the value (e.g., decimal value) represented by this N-bit segment is mapped by the data security process 2330 to a new value (e.g., decimal value) under operation of P, and then the binary digits used to represent this new value (e.g., decimal value) becomes the corresponding N-bit output segment for the given N-bit segment.
- the data security process 2320 of the appliance 2300 then invokes (e.g., calls) the communication process 2320.
- the communication process 2320 creates the PUBLISH message 2600 by populating the header field 2620 with the topic name "QEP” and by populating the payload field 2630 with the aforementioned N-bit output segment, denoted 2660.
- the PUBLISH message 2600 is then sent onto the Internet by the appliance 2300 and reaches the broker 2280.
- the broker 2280 receives the PUBLISH message sent by the appliance 2300, recognizes the topic "QEP" in the header field 2620, recognizes that the application device 2220 subscribes to the topic "QEP” and routes the PUBLISH message 2600 towards the application device 2220.
- the routed PUBLISH message is given reference numeral 2600* to distinguish it from the PUBLISH message 2600 received by the broker 2280, since there will be processing by the broker 2280. However, the content of the two messages 2600, 2600* is identical. It is noted that no change to the MQTT protocol is required for communication of sensitive data to take place in the entropy space so that the quantropized data reaches the application device 2220.
- the communication process 2820 of the application device 2220 determines that the topic of the received PUBLISH message 2600* is "QEP", extracts the contents of the payload field 2630* (namely the segment 2660) and invokes (e.g., calls) the data security process 2830.
- the data security process 2380 knows that the received data is quantropized and proceeds to a step of dequantropizing the N-bit segment 2660 in the payload field 2630* of the received PUBLISH message 2600*.
- the value represented by the N-bit segment is mapped by the data security process 2830 to a new value under operation of the permutation matrix P T , and then the binary digits used to represent this new value form the corresponding N-bit output segment.
- the N-bit output segment may be combined with earlier such segments and then assembled by the data security process 2830 into an output bit string 2670 of suitably sized characters (e.g., bytes) that may be further processed by the data processing process 2850 to derive useful information and lead to actions being taken. It should be noted that due to the encoding and decoding mappings being transposes of one another, bit strings 2650, 2670 are identical.
- step 2760 described above provides a way to re-synchronize the encoding mapping between the application device 2220 and the appliance 2300 in physical proximity to one another, it may be in some instances be desirable to reset or re-synchronize the encoding mapping when the application device 2220 is not in the vicinity of the appliance 2300.
- This remote re-synchronization is now described with additional reference to Figure 29.
- a further topic is created for re- synchronization, under the name "ENTROSYNC”. It is assumed that the IoT-enabled devices (including the application device 2220 and the appliance 2300) are aware of the existence of the topic "ENTROSYNC" and subscribe to this topic.
- the communication process 2820 of the application device 2220 receives a new random seed NEW_QSEED from the seed distributor 2270 (via the broker 2280). As described earlier, this could be a result of regular transmissions by the seed distributor 2270 of PUBLISH messages under the topic "SEED". Alternatively, a special request-response sequence can be designed to result in the release of a seed on demand.
- the data security process 2830 of the application device 2220 generates a new key QKl by applying the current permutation matrix P to the new random seed NEW QSEED.
- the application device 2220 then calls the EntroGen(*) process with the new key QKl as an argument, in order to generate a new permutation matrix P_NEW in preparation for exchanging with the appliance 2300 once it will also be synchronized.
- the application device 2220 sends a PUBLISH message 2935 under the topic "ENTROSYNC" and includes, in the payload, the value of the random seed NEW_QSEED that was used to generate the new key QKl and the new permutation matrix P_NEW.
- the PUBLISH message 2935 reaches the broker 2280, which routes it to the appliance 2300.
- the routed PUBLISH message is given reference numeral 2935* to distinguish it from the PUBLISH message 2935, since there will be processing by the broker 2280.
- the communication process 2320 of the appliance 2300 receives the PUBLISH message 2935, recognizes the topic "ENTROSYNC", and then extracts the new random seed NEW_QSEED from the payload and sends it to the data security process 2330.
- the data security process 2330 of the appliance 2300 generates the same new key QKl by applying the current permutation matrix P to the received new random seed NEW_QSEED.
- the appliance 2300 then calls the EntroGen(*) process with the new key QKl as an argument, in order to generate the same new permutation matrix P_NEW in preparation for exchanging with the application device 2220.
- both the application device 2220 and the appliance 2300 have knowledge of the same new permutation matrix P_NEW.
- the transpose P_NEW T can be easily derived from P_NEW if it is not already known.
- the data security process 2330 of the appliance 2300 can use an encoding mapping represented by the permutation matrix P_NEW while the data security process 2830 of the application device 2220 can use a decoding mapping represented by P_NEW T .
- the data security process 2830 of the application device 2220 can use an encoding mapping represented by the permutation matrix P_NEW T while the data security process 2330 of the appliance 2300 can use a decoding mapping represented by P_NEW.
- Alternative protocols to MQTT to MQTT
- an AMQP message 3110 for seed delivery and an AMQP message 3120 for delivery of quantropized information.
- the general message format of an AMQP message includes a header field 3130, a delivery annotations field 3140, a message annotations field 3150, a properties field 3160, an application properties field 3170, an application data field 3180 and a footer field 3190.
- the properties field 3160 and the application properties field 3170 may be used to convey some of the information described earlier in this document.
- the properties field 3160 of the AQMP message 3010 for seed delivery may include a type flag (which identifies the type of message), whereas the application properties field 3170 may include the seed itself (e.g., QSEED), the HMAC and the time stamp.
- the properties field 3160 of the AQMP message 3120 for delivery of quantropized information may include a type flag (which identifies the type of message), the seed identifier, the HMAC and the time stamp, whereas the application data field 3170 may contain the quantropized data itself.
- a user can use a blockchain to securely store sensitive data (such as the initial secret for a cryptographic exchange, confidential government or corporate data, surveillance video, any other sensitive data) for its own private use.
- sensitive data such as the initial secret for a cryptographic exchange, confidential government or corporate data, surveillance video, any other sensitive data
- a user in a blockchain network that has a wallet with a private key and a public key.
- the user can store the sensitive data on a local device (e.g., smartphone, desktop) and, as a backup, on the blockchain. This can be done by using the public key to encrypt the sensitive data, and recording it as a transaction on the blockchain.
- Other users cannot decrypt the sensitive data without the private key. Only the user can decrypt the sensitive data from the blockchain using the private key.
- the wallet needs to be backed up securely by the user, not the data, which remains securely located in the cloud.
- This can be used for cloud-based secure backup storage.
- the user if the user is using a new device (for example, a new smartphone after the previous one was lost or stolen), the user obtains a backup copy of the wallet (including the private key). Then the encrypted sensitive data is downloaded from the blockchain and decrypted using the private key to obtain the sensitive data in decrypted form.
- the user device 2010 can be a smartphone or computer, which is configured to be capable of carrying out quantropization as described herein and to this end includes a control module 2015 for determining the correct encoding and decoding mappings to use.
- the user device 2010 wishes to upload a file using the blockchain so as to, for example, store the file for future access.
- the file can be sliced into one or more file blocks.
- a server 2020 is also present in this blockchain-enabled environment and is configured for broadcasting seeds from time to time. In addition, the server 2020 maintains a historical record of the seeds it has broadcast, together with their time ranges.
- the control module 2015 of the user device 2010 can generate a succession of keys QK1, QK2, etc. with the aid of one or more permutation matrices PI, P2, etc. as has been described previously. That is to say:
- the metadata of the file is first encrypted (using by AES) with the current key QKi; the result is denoted AES(metadata). Then the encrypted metadata is written on the blockchain as a transaction with a user ID, the timestamp and a signature.
- AES hashed message authentication code
- HMAC hashed message authentication code
- the user in the event that the user's private key being used to carry out the transactions on the blockchain is cracked (e.g., by a quantum computer) or stolen, the user can still identify authentic and fake transactions by verifying the HMAC along with each transaction record. Also, a checksum value related to the file data may be produced and added as part of the transaction. This can be used once the file is downloaded to test for data integrity.
- Each file block FID is then encrypted using the same technique and with the same key QKi (unless changes have occurred in the meantime).
- the entire encrypted file block is hashed, e.g., using SHA256. Then this hash is uploaded to the blockchain, along with User ID, sequence number, HMAC, timestamp and signature of the user.
- the second user device 2050 can be another smartphone or computer which, similar to user device 2010, is configured to be capable of carrying out quantropization as described herein and to this end includes a control module 2055 for determining the correct encoding and decoding mappings to use.
- the second user device 2050 firsts download the encrypted metadata from the blockchain.
- the integrity of the file metadata will be verified by the HMAC.
- the metadata can be decrypted by AES using the correct key QKi generated with the correct seed SEEDi.
- the correct value of "i" can be retrieved from the server 2020 based on the timestamp stored in the file.
- the decrypted metadata will tell the second user device 2050 which file blocks (FIDs) to download (and from which storage nodes) as well as their sequence. Then the second user device 2050 will download the all encrypted file blocks and decrypt them using the same mechanism. The integrity of each file block will be verified by HMAC. Finally, the device will concatenate the file blocks to formulate the original file. The file can be verified by the checksum value.
- FIDs file blocks
- the witnessed message may in some embodiments comprise a blockchain transaction.
- the system includes two peers, Alice and Bob, as well as a witnessing entity, referred to as "William".
- William represents a computing device that could be accessible to Alice and Bob over a network 990 such as the internet. This could be in the context of an online service provided by William, and which charges a fee for each witnessed transaction, for example.
- Alice and William have securely built up a common Entropy History Table (as described above), including entropy records.
- an entropy record includes a plurality of entries, which may include an ID of the peer associated with the record, a time indicator, an entropy state and a hash.
- a common entropy record is identified between Alice and William.
- the common entropy record may be identified by, for example, agreeing on the 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" (denoted E t ), and which has a corresponding hash H t .
- steps involved in Alice generating a witnessed message WM from an original message M are now described with reference to the diagram in Figure 36. It is assumed that Alice maintains a public-private key pair. Alice's public key PU can be used by Bob and William as an identifier of Alice.
- TokenGen may involve two steps:
- 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.
- 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 to create the signature SIG.
- Alice creates a witnessed message WM with the message M and the signature SIG. This can be done by concatenating the message M and the signature SIG.
- William 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, William retrieves the corresponding hash, and verifies that the retrieved hash matches the hash received from Alice, namely H t . If not, then this would mean that Alice is not using the same Entropy History Table as William, which could signal a security breach.
- the token ledger 3675 may be implemented as a data structure, such as a table, linked list, etc., stored in a database and physically residing in memory.
- the token ledger 3675 may also log other details such as a message ID or session ID.
- 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.
- Bob validates the witnessed message WM received from Alice by carrying out the following:
- obtaining a second data element by joint processing of the second part of the message using a key associated with Alice e.g., decrypting the second part of the message using Alice's public key, whereby Alice's private key would have been used to encrypt the second part of the message and, more specifically to encrypt a result of joint processing, by Alice, of the first part of the message and the token, thereby to create the second part of the message
- validating the witnessed message by comparing the first and second data elements; 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 and second data elements match only when the token received from a key associated with Alice (e.g., decrypting the second part of the message using Alice's public key, whereby Alice's private key would have been used to encrypt the second part of the message and, more specifically to encrypt a result of joint processing, by Alice, of the first part of the message and the token, thereby to create the second
- William matches an original token used by Alice in creating the second part.
- the token created by William and the original token used by Alice in creating the second part are both created from the same entropy data (E).
- This entropy data was obtained by William consulting a ledger based on a code (such as a hash H derived by executing a one-way function on the entropy data) received from Alice.
- Bob provides the signature SIG to William, together with Alice's public key PU (or any other identifier of Alice that would allow William to obtain Alice's public key PU).
- William 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 received from Bob.
- Bob extracts the message M from the witnessed message WM received from Alice, combines it with the token T received from William, and creates an expected digest D. o Meanwhile, Bob uses Alice's public key PU to decrypt the signature SIG, thereby to obtain a decrypted digest D'.
- the above-described process prevents a malicious party that gains access to Alice's private key from generating a valid transaction, even if the malicious party also gains access to the token T. This is because the malicious party does not have access to the Entropy History Table, and therefore the malicious party does not know the current entropy state E t or its corresponding hash H t . Thus, the malicious party cannot successfully instruct William to generate the correct token T for use in the receiving process.
- Alice and William must generate the same token because Bob relies only on William for the token. If the tokens are different, Bob will be unable to verify the message. It is assumed that Alice and William share a privileged/secured relationship. Specifically, William will only generate tokens when directed by Alice. As such, so long as a secured channel can be established between Alice and William, this approach may be more difficult to crack than a conventional approach, even for quantum computers.
- William the witnessing entity
- William is configured to obtain a code (such as a hash) and a signature from Alice, consult a first database (Entropy History table) to obtain entropy data 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.
- the first database is only consulted when there is a match between code obtained from Alice and a code associated with the identifier of Alice.
- the entropy data may represent a configuration of a one-to- one switch with 2 N input ports and 2 N output ports.
- the system includes two peers, Alice and Bob, as well as a witness William.
- William represents a computing device that could be accessible to Alice and Bob over a network such as the internet. It is assumed that Alice and William establish and maintain a common Entropy History Table.
- Alice and William agree on a common entropy record in the Entropy History Table.
- the common entropy record may be identified by, for example, agreeing on a time indicator.
- the common entropy record is associated with the shared entropy state E t which, according to the Entropy History Table, has a corresponding hash H t . It is further assumed that Alice maintains a public-private key pair, and that Alice's public key PU can be used by Bob and William as an identifier of Alice.
- Steps involved in Alice generating a witnessed blockchain transaction WB from an original transaction payload/message B are now described with reference to the diagram in Fig. 39.
- 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.
- Alice creates a witnessed blockchain transaction WB with the transaction ID, the transaction payload/message B and the signature SIG. Meanwhile, Alice informs William that a token was generated, and supplies William with Alice's ID, the signature SIG (which was generated form the message M and the token T), as well as the hash H t corresponding to the current entropy state E t (obtained from the Entropy History Table).
- William Based on Alice's ID, William obtains Alice's public key PU. Based on Alice's public key PU, William retrieves the corresponding hash, and verifies that the retrieved hash matches the hash received from Alice, namely H t . If not, then this would mean that Alice is not using the same Entropy History Table as William, which could signal a security breach.
- 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 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. 37.
- N-bit output bit segments produced through application of an encoding mapping as described herein exist in a space that is so vast that, from a practical perspective, encryption is no longer needed to guarantee security, even for relatively small values of N. Nevertheless, the security provided by the use of an encoding mapping as described herein can be further enhanced. For example, one can use more than one permutation matrix in series, or avoid the use of common encoding lengths such as 8 bits (with ASCII) or 16 bits (with Unicode), in order to reduce the presence of a statistically significant fingerprint in the output bit stream that could help reverse engineer the input bit stream. Also, one can prepend bits into the input bit stream to alter the "frame" into which the input bits of the original bit stream are placed.
- Fig. 40 there is shown a multi-level system with two system sizes, N 1 and N2.
- an input bit stream (e.g., provided in 8-bit or 16-bit characters) is first disassembled by a first disassembler 4010 into segments of size Nl. These segments are then quantropized by a first quantropizer 4020 using a first permutation matrix PI of size Nl. The resulting Nl-bit segments are reassembled by a reassembler 4030, which produces segments of size N2.
- the reassembler 4030 may include a packager, which creates 8-bit or 16-bit characters, and then a disassembler, which breaks up the 8-bit or 16-bit characters into N2-bit segments. These N2-bit segments are then quantropized by a second quantropizer 4040 using a second permutation matrix P2 of size N2. The resulting N2-bit segments are then packaged by a packager 4050 into 8-bit or 16-bit characters before being transmitted to the recipient. The recipient side essentially conducts the same operations but in reverse order, starting with N2-bit dequantropization (using permutation matrix P2 T ) and then Nl-bit dequantropization (using permutation matrix P1 T ).
- Nl-bit input segments of an input message are converted into corresponding Nl-bit output segments using a 2 N1 -by-2 N1 one-to-one mapping stored in a non- transitory storage medium; then, the Nl-bit output segments are reassembled into N2-bit input segments, which are then converted into corresponding N2-bit output segments using a 2 N2 -by-2 N2 one-to-one mapping.
- the 2 N1 -by-2 N1 one-to-one mapping and the 2 N2 -by-2 N2 one-to-one mapping are stored in a non-transitory storage medium.
- Nl and N2 can be arbitrary integers greater than 1, and N 1 is different from N2.
- an input bit stream (e.g., provided in 8-bit or 16-bit characters) is first disassembled by a first disassembler 4110 into segments of size Nl. These segments are then bit- shuffled by a bit shuffler 4120 of size Nl.
- the bit shuffler 4120 maps input bit positions to output bit positions.
- the resulting Nl-bit segment corresponding to a particular Nl-bit input segment will have the same number of ones and the same number of zeros as the particular Nl-bit input segment, only at different positions.
- Nl is not equal to 8 or 16
- the Nl-bit segments are then disassembled by a disassembler 4130, which produces segments of size N2.
- These N2-bit segments are then quantropized by a quantropizer 4140 using a permutation matrix P of size N2.
- the resulting N2-bit segments are then packaged by a packager 4150 into 8-bit or 16-bit characters before being transmitted to the recipient.
- the recipient side essentially conducts the same operations but in reverse order, starting with N2-bit dequantropization (using permutation matrix P2 T ) and then Nl-bit deshuffling.
- an input bit stream (e.g., provided in 8-bit or 16-bit characters) is first disassembled by a disassembler 4210 into batches of four segments of size N.
- the first such segment in each batch is sent to the first quantropizer 4200 for quantropization using a first permutation matrix P 1 of size N.
- the second segment in each batch is sent to the second quantropizer 4202 for quantropization using a second permutation matrix P2 of size N.
- the third segment in each batch is sent to the third quantropizer 4204 for quantropization using a third permutation matrix P3 of size N.
- the fourth segment in each batch is sent to the fourth quantropizer 4206 for quantropization using a fourth permutation matrix P4 of size N.
- the resulting batch of four N-bit segments is reassembled by a packager 4020, which transforms the sequence of four sets of N bits into 8-bit or 16-bit characters for transmission to the recipient.
- the recipient side essentially conducts the same operations but in reverse order. It should be understood that the number of quantropizers in the block is not limited to four, and could be a greater or smaller number.
- a quantropization system that includes a disassembler 4310, a dynamic spreader 4320 (also referred to as a "scrambler") and a quantropizer 4330.
- the dynamic spreader 4320 processes L-bit input segments in batches of 2 L such segments.
- the dynamic spreader 4320 keeps track of the position (i.e., 0 to 2 L -1) of each L-bit input segment 4340 within each batch of 2 L such input segments.
- the dynamic spreader 4320 also maintains 2 L mutually exclusive templates 4350 for bit-toggling, one for each position (i.e., 0 to 2 L -1).
- the 2 L mutually exclusive templates 4350 could be, for example, the 2 -1 possible combinations of zeros and ones possible with N bits.
- the mutually exclusive templates 4350 could be stored in a memory of the dynamic spreader 4320.
- the dynamic spreader 4320 then combines the 0 th L-bit input segment with the 0 th template to yield the 0 th L-bit "intermediate" segment.
- the dynamic spreader 4320 combines the 1 st L-bit input segment with the 1 st template to yield the 1 st L-bit intermediate segment, and so on. By “combining", this could include a variety of invertible functions, such as exclusive or (XOR).
- the dynamic spreader 4320 will produce an ordered sequence of 2 L L-bit intermediate segments 4360, which are fed, in sequence, to the quantropizer 4330 via the disassembler 4310.
- the disassembler 4310 converts the sequence of 2 L L-bit intermediate segments 4360 into a sequence of N-bit segments 4340 ready for quantropization.
- the quantropizer 4330 conducts a quantropization process using an encoding mapping (e.g., characterized by a permutation matrix P).
- the system size, N, of the quantropizer 4330 may be the same as the system size, L, of the dynamic spreader 4320.
- the dynamic spreader 4320 and the quantropizer 4330 may operate with different system sizes.
- a dequantropization process is conducted by a dequantropizer and then a dynamic despreading operation is performed by a dynamic despreader.
- the dynamic despreader may perform exactly the same operation (e.g., XOR) as the dynamic spreader 4320, or a different inverse operation.
- the templates 4350 used by the dynamic spreader 4320 may be fixed. In other embodiments, the templates 4350 used by the dynamic spreader 4320 may be dynamic, which means that the templates 4350 may be adjusted over time. In an example, a given template may be XORed with a "salt", and this salt has to be also applied inversely at the dynamic despreader.
- a quantropization system that includes a quantum entropy processor 4450 with a disassembler 4460, a quantropizer 4470 and a packager 4480. Also provided is a dynamic spreader 4490, which in this embodiment could be a stream cipher (such as RC4, for example).
- the dynamic spreader 4490 and the quantropizer 4470 are initialized with the appropriate entropy state E t , which allows the quantropizer 4470 to generate the appropriate permutation matrix P and serves as a seed for the dynamic spreader 4490.
- the entropy state E t can be obtained by consulting an Entropy History Table 4495.
- a communication system comprising:
- a first apparatus comprising a first processing entity coupled to a first memory
- a second apparatus comprising a second processing entity coupled to a second memory
- the first memory stores first computer-readable instructions and a first mapping between 2 N possible input indexes and 2 N possible output indexes, N being an integer greater than one;
- the second memory stores second computer-readable instructions and a second mapping between 2 N possible input indexes and 2 N possible output indexes, the second mapping being derivable from the first mapping;
- the first processing entity is configured for:
- the second processing entity is further configured to process the flag and to store in the second memory the transmitted mapping when the flag indicates that the transmitted mapping is the transpose of the first mapping.
- the second processing entity is further configured to process the flag and to store in the second memory a transpose of the transmitted mapping when the flag indicates that the transmitted mapping is the first mapping.
- the first processing entity is configured for using a private key of a private key / public key pair to encrypt the data indicative of the transmitted mapping, the private key being uniquely known to the first apparatus, the public key being made available to the second apparatus.
- the first mapping is stored in the first memory by a permutation matrix, wherein determining the first output index based on the first input index and the first mapping comprises creating a 2 N -length input vector with all zeroes except for a "1" in a single position corresponding to the first input index, multiplying the permutation matrix and the input vector to obtain a 2 N -length output vector having all zeroes except for a "1" in a single position, wherein the first output index is set to equal the position in which the "1" appears in the output vector.
- the first processing entity is configured for:
- the first processing entity being further configured encrypting the first bit stream with an encryption key before said subdividing
- the second processing entity being further configured for decrypting the third bit stream with a decryption key corresponding to the encryption key, thereby to recover the first bit stream.
- a data protection method comprising:
- N being an integer greater than one
- a method of implementing a secure network amongst a plurality of communication devices comprising:
Landscapes
- Engineering & Computer Science (AREA)
- Business, Economics & Management (AREA)
- Accounting & Taxation (AREA)
- Computer Security & Cryptography (AREA)
- Finance (AREA)
- Signal Processing (AREA)
- Computer Networks & Wireless Communication (AREA)
- Strategic Management (AREA)
- Physics & Mathematics (AREA)
- General Business, Economics & Management (AREA)
- General Physics & Mathematics (AREA)
- Theoretical Computer Science (AREA)
- Development Economics (AREA)
- Economics (AREA)
- Information Transfer Between Computers (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
Abstract
Description
Claims
Applications Claiming Priority (3)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US15/796,577 US10476664B2 (en) | 2017-10-27 | 2017-10-27 | Methods and systems for data protection |
US201862662819P | 2018-04-26 | 2018-04-26 | |
PCT/CA2018/051339 WO2019079890A1 (en) | 2017-10-27 | 2018-10-23 | Methods and systems for secure data communication |
Publications (2)
Publication Number | Publication Date |
---|---|
EP3701664A1 true EP3701664A1 (en) | 2020-09-02 |
EP3701664A4 EP3701664A4 (en) | 2021-07-28 |
Family
ID=66246150
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
EP18870501.6A Pending EP3701664A4 (en) | 2017-10-27 | 2018-10-23 | Methods and systems for secure data communication |
Country Status (5)
Country | Link |
---|---|
EP (1) | EP3701664A4 (en) |
CN (1) | CN111201749B (en) |
AU (1) | AU2018355917B2 (en) |
CA (1) | CA3073549C (en) |
WO (2) | WO2019079890A1 (en) |
Cited By (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US11621841B2 (en) | 2021-04-15 | 2023-04-04 | Real Random IP, LLC | System and method for secure end-to-end electronic communication using a privately shared table of entropy |
Families Citing this family (16)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US11323247B2 (en) | 2017-10-27 | 2022-05-03 | Quantropi Inc. | Methods and systems for secure data communication |
US10608829B1 (en) * | 2018-10-08 | 2020-03-31 | International Business Machines Corporation | Blockchain timestamp agreement |
US11924360B2 (en) | 2018-10-08 | 2024-03-05 | Green Market Square Limited | Blockchain timestamp agreement |
CA3135046C (en) | 2019-04-23 | 2022-10-04 | Quantropi Inc. | Enhanced randomness for digital systems |
US11228431B2 (en) | 2019-09-20 | 2022-01-18 | General Electric Company | Communication systems and methods for authenticating data packets within network flow |
CN112632568B (en) * | 2019-10-08 | 2022-11-29 | 上海唯链信息科技有限公司 | Temperature data storage and acquisition method, system, electronic equipment and storage medium |
CN113271202B (en) * | 2020-02-14 | 2022-05-31 | 中移(苏州)软件技术有限公司 | Data encryption method and device |
US11329797B2 (en) | 2020-02-25 | 2022-05-10 | Quantropi Inc. | Method and system for secure phase-encoded digital communication over optical channels |
WO2022079466A1 (en) * | 2020-10-13 | 2022-04-21 | Chan Kam Fu | Data authentication for data compression |
US11515035B1 (en) | 2020-10-16 | 2022-11-29 | Express Scripts Strategic Development, Inc. | Automated device efficacy determination systems for health monitoring devices |
US11929163B1 (en) | 2020-10-16 | 2024-03-12 | Express Scripts Strategic Development, Inc. | Automated device efficacy determination systems for health monitoring devices |
US11967973B2 (en) | 2021-05-06 | 2024-04-23 | Samsung Display Co., Ltd. | Low overhead transition encoding codes |
CN112910933B (en) * | 2021-05-07 | 2021-07-13 | 鹏城实验室 | Authentication method, authentication device, and verification device |
CN114254400B (en) * | 2021-12-27 | 2024-05-03 | 中国人民解放军战略支援部队信息工程大学 | Method and system for defending overflow attack of stack buffer based on dynamic shadow stack |
US20230393762A1 (en) * | 2022-06-02 | 2023-12-07 | Micron Technology, Inc. | Verified key replacement in secure memory devices |
DE102022004632B3 (en) | 2022-12-12 | 2024-03-21 | Mercedes-Benz Group AG | Method for encrypting plain text |
Family Cites Families (10)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
WO2002017539A2 (en) * | 2000-08-18 | 2002-02-28 | Distributed Trust Management Inc. | Distributed information system and protocol for affixing electronic signatures and authenticating documents |
US7747019B2 (en) * | 2005-09-28 | 2010-06-29 | Nortel Networks Limited | Methods and systems for communicating over a quantum channel |
US7761596B2 (en) * | 2006-06-30 | 2010-07-20 | Telefonaktiebolaget L M Ericsson (Publ) | Router and method for server load balancing |
CA2638134A1 (en) * | 2008-07-21 | 2010-01-21 | Randy Kuang | Multi-dimensional cryptography |
CN101610510B (en) * | 2009-06-10 | 2012-06-27 | 南京邮电大学 | Node legitimacy multiple-authentication method in layer cluster type wireless self-organization network |
US8169887B2 (en) * | 2009-12-29 | 2012-05-01 | Industrial Technology Research Institute | Apparatuses and methods for wireless communications using a permutation sequence |
EP2619758B1 (en) * | 2010-10-15 | 2015-08-19 | Huawei Technologies Co., Ltd. | Audio signal transformer and inverse transformer, methods for audio signal analysis and synthesis |
CN104335218B (en) * | 2012-03-30 | 2017-08-11 | 爱迪德技术有限公司 | Addressable system is protected using basic function coding |
CN103000181B (en) * | 2013-01-10 | 2015-02-11 | 成都零光量子科技有限公司 | System and implement method thereof for secret communications based on public communication network voice channel |
US9455962B2 (en) * | 2013-09-22 | 2016-09-27 | Winbond Electronics Corporation | Protecting memory interface |
-
2018
- 2018-10-23 AU AU2018355917A patent/AU2018355917B2/en active Active
- 2018-10-23 EP EP18870501.6A patent/EP3701664A4/en active Pending
- 2018-10-23 CA CA3073549A patent/CA3073549C/en active Active
- 2018-10-23 CN CN201880057218.7A patent/CN111201749B/en active Active
- 2018-10-23 WO PCT/CA2018/051339 patent/WO2019079890A1/en unknown
-
2019
- 2019-01-25 WO PCT/CA2019/050093 patent/WO2020082160A1/en active Application Filing
Cited By (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US11621841B2 (en) | 2021-04-15 | 2023-04-04 | Real Random IP, LLC | System and method for secure end-to-end electronic communication using a privately shared table of entropy |
US11924339B2 (en) | 2021-04-15 | 2024-03-05 | Real Random IP, LLC | System and method for secure end-to-end electronic communication using a privately shared table of entropy |
Also Published As
Publication number | Publication date |
---|---|
WO2019079890A1 (en) | 2019-05-02 |
AU2018355917A1 (en) | 2020-02-13 |
CN111201749B (en) | 2021-09-28 |
CA3073549C (en) | 2021-06-08 |
WO2020082160A1 (en) | 2020-04-30 |
CN111201749A (en) | 2020-05-26 |
CA3073549A1 (en) | 2019-05-02 |
EP3701664A4 (en) | 2021-07-28 |
AU2018355917B2 (en) | 2020-09-24 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US11323247B2 (en) | Methods and systems for secure data communication | |
AU2018355917B2 (en) | Methods and systems for secure data communication | |
US10693848B2 (en) | Installation of a terminal in a secure system | |
EP3205048B1 (en) | Generating a symmetric encryption key | |
CN111526197B (en) | Cloud data secure sharing method | |
US10356090B2 (en) | Method and system for establishing a secure communication channel | |
CN103427998A (en) | Internet data distribution oriented identity authentication and data encryption method | |
US10476664B2 (en) | Methods and systems for data protection | |
US20150229621A1 (en) | One-time-pad data encryption in communication channels | |
US10733309B2 (en) | Security through authentication tokens | |
US20180063131A1 (en) | Mutual authentication | |
US11621835B2 (en) | Relay network for encryption system | |
CN114244508B (en) | Data encryption method, device, equipment and storage medium | |
KR20230175185A (en) | File sharing method and system based on the safety of national password algorithm | |
CN111884988A (en) | Method for secure transmission of data | |
CN114143098A (en) | Data storage method and data storage device | |
CN116668137A (en) | End-to-end encryption communication method, equipment and medium between industrial Internet equipment | |
CN117675205A (en) | Data security transmission method | |
KR20170109958A (en) | Information security device |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
STAA | Information on the status of an ep patent application or granted ep patent |
Free format text: STATUS: THE INTERNATIONAL PUBLICATION HAS BEEN MADE |
|
PUAI | Public reference made under article 153(3) epc to a published international application that has entered the european phase |
Free format text: ORIGINAL CODE: 0009012 |
|
STAA | Information on the status of an ep patent application or granted ep patent |
Free format text: STATUS: REQUEST FOR EXAMINATION WAS MADE |
|
17P | Request for examination filed |
Effective date: 20200225 |
|
AK | Designated contracting states |
Kind code of ref document: A1 Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO RS SE SI SK SM TR |
|
AX | Request for extension of the european patent |
Extension state: BA ME |
|
DAV | Request for validation of the european patent (deleted) | ||
DAX | Request for extension of the european patent (deleted) | ||
RAP3 | Party data changed (applicant data changed or rights of an application transferred) |
Owner name: QUANTROPI INC. |
|
A4 | Supplementary search report drawn up and despatched |
Effective date: 20210629 |
|
RIC1 | Information provided on ipc code assigned before grant |
Ipc: H04L 9/00 20060101AFI20210623BHEP Ipc: G06Q 20/06 20120101ALI20210623BHEP Ipc: H03M 7/00 20060101ALI20210623BHEP Ipc: H04L 7/00 20060101ALI20210623BHEP Ipc: H04L 9/32 20060101ALI20210623BHEP Ipc: H04L 9/06 20060101ALI20210623BHEP Ipc: H04L 9/08 20060101ALI20210623BHEP Ipc: G06Q 20/38 20120101ALI20210623BHEP |
|
STAA | Information on the status of an ep patent application or granted ep patent |
Free format text: STATUS: EXAMINATION IS IN PROGRESS |
|
17Q | First examination report despatched |
Effective date: 20230324 |