GB2577494A

GB2577494A - Feature(s) generation

Info

Publication number: GB2577494A
Application number: GB1815593.7A
Authority: GB
Inventors: Guo Weisi
Original assignee: University of Warwick
Current assignee: University of Warwick
Priority date: 2018-09-25
Filing date: 2018-09-25
Publication date: 2020-04-01
Also published as: GB201815593D0

Abstract

A method comprises extracting 10 data or metadata 11 selected in dependence upon an identity of a counterpart user 8 with whom the data has been exchanged, extracting 12 at least one characterising feature 15 from the data or metadata using a predefined extraction method, and storing the at least one feature in a memory 14. The at least one feature may either be used as an encryption key 25 or used in a process of key generation prior to transmitting encrypted data. Features may include text in a given position, emojis, time of arrival or sending, and image-specific features such as RGB colour data and image size. Based on such features extracted from previous communications between devices, a common memory 14 shared between and specific to a pair of devices may be developed. Keys generated based on such shared memory need not be exchanged over insecure public channels nor derived from a public key pool. Such shared memory may be unique to and identical between an intended user pair, and may dynamically vary over time to prevent brute force attacks.

Description

Feature(s) generation

Field

The present invention relates generating feature(s) for use in generating an encryption key.

Background

Encryption in communications typically involves exchanging cipher keys or prearranged keys (i.e., pre-shared secret). The exchange of keys, however, is vulnerable to ro an eavesdropper interception. Pre-shared keys are vulnerable to brute force hacks in the key generation scheme, allowing eavesdropper to replicate the process. Other mechanisms such as Public-Key or asymmetric cryptography requires a private key to be kept, which can still be hacked.

Recently it has been shown that this is not necessary to share a key in wireless radio channels. Physical Layer Security (PLS) exploits common, unique, dynamic physical properties of a radio signal between users to generate a common key without the need to exchange it. Thus, an eavesdropper cannot intercept the key. Furthermore, the dynamic nature of PLS helps to ensure that brute force attacks are unlikely to be successful. However, PLS is only available over a direct radio link. More general end-to-end communications between A and B may take place over many telecommunications links, which may include wireless and wired links.

Summary

According to a first aspect of the present invention there is provided a method of generating feature(s) for use in generating an encryption key. The method comprises extracting data or metadata selected in dependence upon an identity of a counterpart user with whom the data has been exchanged, extracting at least one characterising feature from the data or metadata using a predefined extraction method and storing the at least one characterising feature associated with the counterpart user.

The data may be text (such a text message or a file containing text) and the characterising feature may be an extract of the text, time of sending or time of arrival, a length or size of the text. The data may include one or more images (such a photo for example in the form of jpeg, gif or other image format) and the characterising features may be an RGB colormap, size of image (e.g. measured in MB), or time of sending or time of arrival. The data may include a sound file (which may be in the form of an mp3, way or other format), such as a voice message, and the characterising may be the duration of message or frequency spectrum of sound.

At least some of the data or the metadata (e.g., all of the data or the metadata) may be locally-stored (in other words, in non-volatile memory in the same device that performs 20 the method). The data or the metadata may be deleted.

The characterising feature may be stored in a predefined or pre-agreed format so allowing different characterising features to be expressed in the same common format. Thus, characterising features from different sources (such as different software applications) can be used in combination or interchangeably to generate an encryption key.

The method may further comprise using the at least one feature as an encryption key or generating an encryption key using the at least one feature in a predefined manner of 30 key generation.

The method may comprise encrypting data using the encryption key to provide encrypted data and transmitting the encrypted data. The method may comprise receiving encrypted data; and decrypting the encrypted data using the encryption key to 35 provide decrypted data. -3 -

According to a second aspect of the present invention is provided a computer program comprising instructions for performing the method of the first aspect.

According to a second aspect of the present invention is provided a hardware accelerator configured to perform the method of the first aspect. The provided a hardware accelerator may be an FPGA or an ASIC.

According to a third aspect of the present invention is provided memory storing at least one characterising feature associated with an identity of a counterpart user with whom data has been exchanged, the at least one characterising feature extracted from the data in dependence upon the identity of counterpart user, the at least one characterising feature extracted using a predefined extraction method.

The memory may be removable, for example, a dongle or USB memory stick, or may be transferable, for example, via a communications network, e.g., via the Cloud.

The memory may comprise a plurality of sets of characterising features, each set of characterising features associated with an identity of a respective counterpart user.

The characteristic features may be associated with more than two users, for example, three or more users.

According to a fourth aspect of the present invention is provided a method comprising: identifying a counterpart user, receiving at least one characterising feature from the at least one characterising feature stored in the memory of the third aspect of the invention in dependence on the identity of the counterpart user; and generating an encryption key using the at least one characterising feature received from the memory.

The method may further comprise consolidating features and/or the encryption key 30 such that there is agreement The method may further comprise encrypting data using the encryption key and/or decrypting encrypted data using the encryption key. The method may further comprise transmitting data which has been encrypted using the encryption key and/or receiving 35 the encrypted data. -4 -

According to a fifth aspect of the present invention is provided a computer program comprising instructions for performing the method of the fourth aspect.

According to a sixth aspect of the present invention is provided a computer program 5 product comprising a computer readable medium (which may be non-transitory) storing the computer program of the second or fifth aspect.

According to a seventh aspect of the present invention there is provided a communications terminal comprising at least one processor or hardware accelerator and memory. The at least one processor configured to perform the method of the first or the fourth aspect of the invention. The communications terminal may be a mobile communications device, such as a mobile phone, lap-top computer, or tablet computer. The communications terminal may be a fixed or semi-fixed communications device, such as a desk-top computer. The communications terminal may be a sensor, which may be installed remotely. -5 -

Brief Description of the Drawings

Certain embodiments of the present invention will now be described, by way of example, with reference to the accompanying drawings, in which: Figure 1 is a schematic block diagram of first and second user devices employing common memory shared between two communicating users to generate an encryption key; Figure 2 illustrate shared memory generation; Figure 3 illustrate encryption key generation; and Figure 4 shows a simple example of using a shared memory.

Detailed Description of Certain Embodiments

Referring to Figure 1, a system 1 is shown which includes first and second user devices 2A, 2B (herein also referred to as "user A device" and "user B device" respectively) which can communicate through an end-to-end communication link 3 via at least one network /5 4. First and second users A, B (not shown) access their respective devices using suitable credentials or other authentication arrangements.

The user devices 24, 211 can take the form of a mobile computing device (such as a smart phone or tablet) or a laptop computer, or a non-mobile (or "fixed") computing device, such as a desktop computer or workstation. The user devices 2A, 2B may communicate via one or more wired networks, one or more wireless networks or a combination of one or more wired and one or more wireless networks.

Software applications 5,, 52 are installed on each user device 2a, 2B and can provide respective common application data 6b 62 associated with the application 5. For example, an application 5, on one device 2A may generate, store, use, transmit, or receive the application data 6, which is consumed, stored, used, received or transmitted by a corresponding application 5, on the other device 2u.

Each user device 2A, 2B includes a first module 7 (herein referred to as an "identity module") storing the identities 8 of other users, a second module 9 (herein referred to as an "memory module") storing a shared memory 14 (or "common memory") specific to the first and second user devices 2A, 2B. As will be explained in more detail later, the shared memory 14 provides common characteristic features 15 (herein referred to as "common random features" or "common randomness") which are used for key generation. -6 -

Each user device 2A, 2B also includes a key generation module 17 which generates a common key 25, an encryption/decryption module 26 and at least one or more network interface module(s) 27.

To achieve secure communications across any media and platforms, an arrangement herein referred to as Memory Layer Security (MLS) is used. MLS exploits the common memory 14 shared between the two communicating user devices 2A, 2B to generate an encryption key 25 without the need to exchange the key 25 over an insecure, public io channel, nor derive or obtain the key 25 from a public key pool. As will be explained in more detail herein after, the shared memory 14 is based on previously-exchanged data and previous communications between the first and second databases 2A, 2E.

Moreover, the key 25 can be updated periodically or evolve over time. Different application data 6h 6, from previous communication instances are converted to form a /5 common, shared memory 14 for the purposes of encryption. The shared memory instance can be kept, even if applications 5h 5, are deleted or data in the applications are erased.

Each user device 2A, 2B identifies other users using the identity module 7, which can include a contact list, which is shared across multiple software applications 5,, 5E. A unique identity can link a user 8 to multiple different applications Si, 5E, such as Facebook (RTM), WhatsApp (RTM), WeChat (RTM), Google Talk (RTM) and the like. Identity spoofing is ineffective if a false user device (not shown) tries to imitate the second user device 24, 213 since they do not share the same common memory 14 as the first and second user devices 2A, 2B.

Breaking the code between a pair of users does not enable the breaking of another pair, as the shared common memory is unique between user pairs. Thus, if an eavesdropper establishes a common memory for, for example, a first user and a second user, then this will not assist the eavesdropper in finding a common memory between the first user and a third, different user.

Moreover, breaking the code between a pair of users at a particular instance in time will not necessarily help the eavesdropper break the code between the same pair of users at 35 a later time if the common memory changes over time and, thus, is time-dependent. -7 -

Referring also to Figure 2, a data extraction module 10k, 102, 103, 104 extracts relevant data lt" 112, 113, 114 from a respective set of application data 6, 6,, 63, 64. For example, the relevant data 11" 112, 113, 114 may take the form of, for example, long text, short text, images or a voice recording. A feature extraction module 12" 12,, 123, 124 extracts features 131, 132, 133, 134 from the relevant data 111, 112, 113, 114. For example, features 13,,132, 133, 134 may take the form of a string, an arrival time, a value of RGB or a duration of time. The extracted features 13,, 13,, 133, 134 form the basis of the common memory 14 between the user device 2A, 28. The extracted features 13±, 132, 133, 134 can take the form of, or be converted into, a common data format, for example, n-bit number, where n may be 16, 32, 64 etc. using a common data format can allow combinations of different extracted features 13" 13,, 133, 134 originating from different applications to be used. The shared memory 14 selects one or more features 131, 13,, 133, 134 according to a predetermined algorithm (which may be as simple as taking successively-stored features or picking features at a fixed intervals) and outputs them as feature(s) 15. The feature extraction algorithms used in the devices 2A, 2B are programmed to work in the same way and the key generation algorithms are designed to exploit the same common memory features.

A memory module 16 is used to control the content of the shared memory 14, e.g., to acquire new data and/or discard old data in predetermined way, e.g., after a given period of time (for example, one year) has elapsed, thus the shared memory can evolve dynamically. Features obtained from older data and/or features derived from data over a longer period can provide greater security.

The shared memory 14 should preferably satisfy three conditions, namely (1) it should be unique between the intended users (i.e., their devices 2A, 2B), such that other users cannot guess or coincidentally have the same memory (2) it should be identical between the intended users or sufficiently close that simple error correction and reconciliation can be used to help ensure that it is identical and (3) it should be dynamic, such that over time it will vary and so help to prevent brute force attacks.

Referring also to Figure 3, to generate the key 25 from the common memory 14, the key generation module 14 may include a quantization module 18, a reconciliation module 20, and a privacy amplification module 22. For example, quantization may be used to transform large arrays of digital data in shared memory into simple binary sequences. Reconciliation maybe used to help ensure that the key both users have is indeed -8 -identical since errors may occur due to, for example, noise in memory and/or cipher generation. Reconciliation can be achieved using standard techniques such as secure sketch and error correction coding. Privacy can be amplified using hash functions.

Referring to Figure 4, a simple example of a shared memory and cipher generation is shown.

User A and user B exchange a series of messages (for example, text messages) which sent at times 1, 7, 12, 13 and 20 (measured in arbitrary time units). The time differences between messages are computed and, this case, the values are 6, 5, i and 7 respectively. The values of 6, 5, 1, 7 are used as cipher key. Both user A and user B can generate the same cipher key locally and independently of each other based on their shared past history of messages. No cipher key is exchanged in public.

/5 Without transferring the cipher over the public channels, an eavesdropper E cannot decode intercepted messages. Even if the eavesdropper E can have access to partial shared memory, the cipher key cannot be regenerated.

As explained hereinbefore, the shared memory 14 can be generated using data or meta-data from a number of different applications and communication data types (herein collectively referred to as "sources"). For example, messages can be used and features can include text (e.g., the text found in given position), emojis, time of sending or time of arrival or length of text. In another example, images can be used and the features can include RGB colormap, size of image (e.g. measured in MB), and time of sending or time of arrival. In yet another example, voice messages may be used and the feature may be duration of message or frequency spectrum of sound. These sources can be across any applications that share a common contact identity list or linked profiles, e.g. phone contact list, Facebook-Instagram contact, Google, Yahoo-Flickr. The application scenarios cover all end-to-end messaging and communication scenarios, as well as file sharing, payment, and command and control applications.

There may be a shared, pre-programmed feature-extraction program between all users. There may be a shared, pre-stored library of characterising features which allows users to start communicating using a common memory. -9 -

The users may be able to generate or add their own characterising features, and/or agree on which characterising features to use, on an ad hoc basis which may be shared or communicated through, for example, a voice channel, text or other communication channel or medium. The users can later switch to a different set of characterising features.

MLS operates independently of communication network technology and data application and can be used as long as the first and second users a shared history of communicating. This can help provide immunity to interception of cipher key(s) as they are not transmitted and can enable encryption across a wide variety of forms of communication networks and data applications.

If a user deletes at least some of their data, for example, as a result of a reset hardware or purposeful erasure), then measures can be taken maintain features stored in the shared memory. For example, each device may be configured to keep track of identities and all messages/pictures/voice as-and-when received and continually generate features.

Modifications It will be appreciated that various modifications may be made to the embodiments hereinbefore described. Such modifications may involve equivalent and other features which are already known in the design, manufacture and use of encryption systems and component parts thereof and which may be used instead of or in addition to features already described herein. Features of one embodiment may be replaced or supplemented by features of another embodiment.

In the example herein describes, common random features are generated for two users.

However, common random features may be generated for more than two users.

The common memory may be transferred from one user device to another, different user device of the same user, for example, by using a removable memory (such as a USB stick) or by transferring the memory, e.g. via the Cloud or via another communications network.

Although claims have been formulated in this application to particular combinations of 35 features, it should be understood that the scope of the disclosure of the present invention also includes any novel features or any novel combination of features -10 -disclosed herein either explicitly or implicitly or any generalization thereof, whether or not it relates to the same invention as presently claimed in any claim and whether or not it mitigates any or all of the same technical problems as does the present invention. The applicants hereby give notice that new claims maybe formulated to such features and/or combinations of such features during the prosecution of the present application or of any further application derived therefrom.