Classifications

• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
  • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
  • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
  • H04L9/0816—Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
  • H04L9/0819—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s)
  • H04L9/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
  • H04L63/00—Network architectures or network communication protocols for network security
  • H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
  • H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
  • H04L63/00—Network architectures or network communication protocols for network security
  • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
  • H04L63/0861—Network architectures or network communication protocols for network security for authentication of entities using biometrical features, e.g. fingerprint, retina-scan
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
  • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
  • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
  • H04L9/0861—Generation of secret information including derivation or calculation of cryptographic keys or passwords
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
  • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
  • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
  • H04L9/0861—Generation of secret information including derivation or calculation of cryptographic keys or passwords
  • H04L9/0866—Generation of secret information including derivation or calculation of cryptographic keys or passwords involving user or device identifiers, e.g. serial number, physical or biometrical information, DNA, hand-signature or measurable physical characteristics
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
  • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
  • H04L9/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/3271—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 challenge-response

Definitions

• Typical transactions may be to look at or share data, to place orders for goods, or to communicate in either open or closed groups. Further transactions may be to carry out financial transactions, including payment of bills, or moving funds from one place or account to another. It is therefore important to verify the identity of a user, before permitting that user to carry out the above.
• problems can occur with lost, stolen, or broken hardware.
• a user's local hardware typically contains a lot of sensitive information. This includes, but is not limited to, 'burnt in' or saved passwords, cookies, browsing history and profiles. If hardware is lost or stolen, this sensitive information can fall into the hands of unscrupulous strangers. If the hardware is broken, it cannot be handed in for repairs without exposing private information to the service centre or repairer.
• passwords with more than 32 random characters should be used on public and local systems. However these are not easily remembered by humans, who want to relate it to another association or fact to be able to recall it. Common passwords are user's dates of birth, names of children, dates of birth of children, names of pets, and so on. These are easily 'guessable' by parties who should not have access, including the criminal fraternity. It has also been shown that if users are made to use long or complicated passwords they often write them down, and of course by having or leaving copies of this password around it negates the point of passwords.
• SSO Single Sign on'
• At least the preferred embodiments of the present invention seek to provide a system which satisfies some or all of the above requirements.
• the present invention provides a method comprising: generating, at least partially on a physical or virtual authentication tool controlled by a user, an intermediate key based on a user code provided by the user and a unique code contained in the authentication tool; accessing an encrypted cryptographic key, wherein the encrypted cryptographic key is not stored in the authentication tool; accessing an offset value associated with the encrypted cryptographic key and the authentication tool; applying the offset value to the intermediate key to generate a decryption key; and locally decrypting the encrypted cryptographic key using the offset decryption key to give a decrypted cryptographic key.
• This technique allows the user to use a simple logon to access their cryptographic keys, which do not then need to be remembered and so can be very long. This allows the user to securely authenticate themself or securely encrypt data.
• the data is not stored on the authentication tool itself, loss of the tool itself does not risk the data being accessed.
• the encrypted cryptographic can be stored even in semi-public servers without concern that they could be accessed by the service provider operating those servers.
• the use of the offset allows multiple authentication tools to access the same encrypted data, thus allowing the user to continue to access the data in the event of loss of one tool, without need for a central service provider who would then need to have access to the user's cryptographic keys.
• the authentication tool may comprise a physical device.
• the physical device may be a portable device suitable for being carried by the user, e.g. on their person.
• the physical device may have a mass of less than 0.5kg, preferably less than 0.1 kg, and/or a volume of less than 500cm 3 , preferably less than 100cm 3 .
• the physical device may be stored at a remote location from the user.
• the physical device may be accessible electronically, e.g. via the Internet or other network.
• the physical device may, however, still be suitable for being carried by the user, if desired.
• the authentication too may comprise a virtual device.
• the authentication tool may comprise a software application and a virtual container for storing the unique code.
• the method may comprise loading the unique code into the virtual container responsive to a request from the user.
• the virtual device may be stored in the cloud.
• the virtual device may be stored alongside a plurality of other authentication tools, which may be controlled by different users.
• the authentication tool is preferably incapable of transmitting the unique code to an external device. Thus, it cannot be accessed by a third party to attack the encrypted cryptographic key.
• the authentication tool may be a physical device.
• authentication tool may be configured to store the unique code in a secure memory.
• the encrypted cryptographic key may be stored on a local computer, i.e. local to the user when accessing the cryptographic key.
• the encrypted cryptographic key is stored in a remote location, and more preferably not normally stored in a local location (i.e. apart from when being accessed).
• the remote location may be a server accessible via a wide-area network (WAN) or via the Internet.
• the server may be a cloud location.
• the server may be over 1 km away from the user.
• the step of locally decrypting the encrypted cryptographic key may be performed on a computing device local to the user and separate from the authentication tool. That is to say, the authentication tool may be removable from the computing device without impairing operation of either the authentication tool or the computing device.
• the authentication tool is a physical device, it may communicate with the computing device wirelessly or via a contact connection.
• the authentication tool is a virtual device, it may communicate with the computing device via a secure communication channel, for example over a WAN such as the internet.
• the computing device may be one of: a personal computer, a desktop computer, a laptop/notebook computer, a tablet computer, a mobile/cellular telephone, a personal digital assistant, or similar personal computing device.
• the intermediate key and/or the decryption key may be stored in a memory of the computing device, and preferably in a volatile memory of the computing device.
• the intermediate key and/or the decryption key may be deleted from the memory of the computing device responsive to interruption of communication between the authentication tool and the computing device.
• the decrypted cryptographic key may be stored in a memory of the computing device, and preferably in a volatile memory of the computing device.
• the decrypted cryptographic key may be deleted from the memory of the computing device responsive to interruption of communication between
• data which might be used to attack or remove the encryption on the encrypted cryptographic key may be automatically deleted, for example even if the user forgets to do so.
• the decrypted cryptographic key is preferably never transmitted remotely from the computing device. Thus, cryptographic key is never outside of the control of the user.
• the user code may be at least partially derived from a biometric identifier.
• the cryptographic key may be used for various purposes. For example, it may be a private key associated with a corresponding public key. Alternatively, it may be a symmetrical key, for example to encrypt data to be shared with another party in possession of the same key or to encrypt or decrypt data to be stored.
• the method may further comprise authenticating the user by locally encrypting or decrypting a challenge phrase using the decrypted cryptographic key.
• the authentication may comprise: receiving an encrypted challenge phrase, the challenge phrase having been encrypted with a public key associated with the user; locally decrypting the challenge phrase using the decrypted cryptographic key, which is a private key corresponding to the public key; and sending the decrypted challenge phrase as evidence that the user is in possession of the decrypted private key.
• the authentication may comprise: receiving a challenge phrase; locally encrypting the challenge phrase using the decrypted cryptographic key; and sending the encrypted challenge phrase, wherein the encrypted challenge phrase can be decrypted with a public key associated with the user, as evidence that the user is in possession of the decrypted cryptographic key.
• the method may comprise: receiving encrypted data, wherein the encrypted data is encrypted using a public key, and wherein the decrypted cryptographic key is a private key corresponding to the public key; and locally decrypting the encrypted data using the decrypted cryptographic key.
• the method may comprise: accessing encrypted data, wherein the encrypted data is encrypted using the cryptographic key; and locally decrypting the encrypted data using the decrypted cryptographic key.
• the present invention also provide a method comprising: generating or receiving a cryptographic key; generating, at least partially on a physical or virtual authentication tool controlled by the user, an encryption key based on a user code provided by the user and a unique code contained in the authentication tool; and locally encrypting the cryptographic key using the encryption key to give an encrypted cryptographic key, wherein the encrypted cryptographic key is not then stored in the authentication tool.
• This technique permits the user to locally generate encrypted cryptographic keys, such as for use with the technique described above.
• the cryptographic keys are thus encrypted such that they can only be recovered by the user in possession of the authentication tool and the user's code.
• the encrypted keys can be freely stored, even in semi-public locations.
• the user is fully in control of access to this data and no third party can access it.
• the encrypted cryptographic keys are not stored on the authentication tool itself, and so are not compromised if this is lost, even if the system uses a simple password as the code.
• generating the encryption key may comprise:
• the authentication tool may be incapable of transmitting the unique code to an external device.
• the method may comprise storing the encrypted cryptographic key in a remote location.
• the step of locally encrypting the cryptographic key is preferably performed on a computing device local to the user and separate from the authentication tool.
• the intermediate key and/or the encryption key may be stored in a memory of the computing device, and preferably in a volatile memory of the computing device.
• the intermediate key and/or the encryption key may be deleted from the memory of the computing device responsive to interruption of communication between the authentication tool and the computing device.
• the cryptographic key may be stored in a memory of the computing device, and preferably in a volatile memory of the computing device.
• the cryptographic key may be deleted from the memory of the computing device responsive to interruption of communication between the authentication tool and the computing device.
• the cryptographic key is preferably never transmitted from the computing device in an un-encrypted form.
• the user code may be at least partially derived from a biometric identifier.
• the cryptographic key may be a private key having an associated public key.
• the authentication tool may be a first authentication tool
• the method may comprise generating an offset value to permit a second authentication tool to decrypt the encrypted cryptographic key
• the method may further comprise: generating, at least partially on a second physical or virtual authentication tool controlled by the user, a second intermediate key based on a user code provided by the user and a unique code contained in the second authentication tool; and calculating an offset value to transform the second intermediate key into the decryption key.
• the offset value generated is meaningless to any third party.
• it when applied to an intermediate value generated from the second authentication tool, it allows it to arrive at the same decryption key as would be generated using the first authentication tool.
• the user can have multiple authentication tool as back-ups in case of loss, rather than relying on a third party to also have access in case of the need for recovery.
• the offset value may be stored together with the encrypted cryptographic key. As noted above, in isolation, this offset value is meaningless.
• the offset value may be applied using an XOR function.
• the present invention provides a computer program comprising computer readable instructions that, when executed, will cause a computing device to perform a method comprising: receiving an intermediate key from a physical or virtual authentication tool, the intermediate key having been generated based on a user code provided by the user and a unique code contained on the authentication tool; accessing an encrypted cryptographic key, wherein the encrypted cryptographic key is not stored in the authentication tool; accessing an offset value associated with the encrypted cryptographic key and the authentication tool; applying the offset value to the intermediate key to generate a decryption key; locally decrypting the encrypted cryptographic key using the decryption key to give a decrypted cryptographic key; and locally encrypting or decrypting data using the decrypted cryptographic key.
• the computer program of the third aspect may further be configured to perform any one or more or all of the optional or preferred features carried out in the first aspect, and particularly those associated with the computing device thereof.
• the present invention provides a computer program comprising computer readable instructions that, when executed, will cause a computing device to perform a method comprising: generating or receiving a cryptographic key; receiving an intermediate key from a physical or virtual authentication tool, the encryption key having been generated based on a user code provided by the user and a unique code contained in the authentication tool; generating or receiving an offset value; applying the offset value to the intermediate key to generate an encryption key; and locally encrypting the cryptographic key using the encryption key to give an encrypted cryptographic key, wherein the encrypted cryptographic key is not then stored in and/or with the authentication tool.
• the computer program of the fourth aspect may further be configured to perform any one or more or all of the optional or preferred features carried out in the second aspect, and particularly those associated with the computing device thereof. Furthermore, a single computer program may be provided for performing the functions of the computer programs of both the third and fourth computer programs.
• Figure 1 shows a user interacting with a cryptographic system
• Figure 2 is a flow chart showing a method of generating a cryptographic profile
• Figure 3 is a flow chart showing a method of accessing a cryptographic profile
• Figure 4 is a flow chart showing a method of permitting a second device to access a cryptographic profile.
• the following embodiment relates to a system by which a user may use a simple username/password combination to securely authorise access to a secret cryptographic key associated with the user.
• the secret cryptographic key may be one used to encrypt/decrypt data for secure storage, to securely communicate with a third party or to authenticate the identity of the user, such as by digitally signing a message.
• An physical device 10 storing a secret number that cannot be
• a cryptographic profile including an encrypted private key and
• CSP Client Security Program
• Client User Software which may include general software running on the user's local hardware 20 for dealing with everyday activities such as sending/receiving email, sharing files, logging in to services, etc. using the CSP.
• the EzKey 10 is a physical token or device that may be carried by a user 1.
• the EzKey 10 contains within it a secret number.
• no two EzKeys 10 have the same secret number in them.
• the EzKey 10 is small and portable, and may contain a communications interface, such as a short range wireless data link (such as the industry standard Bluetooth®), for communication with a local computing device 20.
• Suitable devices that meet the security requirements for use as the EzKey 10 may include the CryptoMemory EEPROMS from ATMEL®. These contain multiple, non-readable 64 bit authentication keys. The layout and design of the devices offers no way to read out the original key - it can only be accessed after it has passed through the hashing engine. Many secure features are included in these devices, such as incorporating screening to prevent access to the chip's internal layout by using X-Rays, and the use of non-linear memory cells within the device, so that if the chip were cut open and viewed under a microscope the function cannot be derived.
• the following scenario illustrates an exemplary operation of the EzKey 10 and ancillary elements to carry out self-authentication of the identity of the user 1.
• the user 1 has a login name - for example the name 'George'.
• the username may be part of his real name, a nickname, or merely a login name.
• a computer program such as small script, piece of code, or app runs on a local computing device 20 (for example, the user's desktop computer, laptop, tablet, phone, or other computing device).
• This software program which will be referred to as the Client Security Program (CSP)
• CSP Client Security Program
• This can be a short word, series of letters, or personal data.
• this password can be a simple human memorable piece of data does not limit the security of the present system.
• the user may be an animal lover, and so may have chosen the simple memorable password to be 'dog'.
• the CSP takes in this response (“dog"), and in turn communicates it via a communication link 15 - preferably a 'PAN' (Personal Area Network - a wireless network that has a range of a few metres - such as Bluetooth®).
• the communication link 15 talks to the EzKey 10.
• the EzKey 10 Upon receipt of this password (“dog") the EzKey 10 'fortifies' the username / password combination, by hashing it with the device's secret unique number, to result in a 'strong' password. That is to say, the hashing function has, as one of its inputs, the secret unique number that is 'etched' into the EzKey 10.
• An exemplary hashing technique includes the SHA-2 (Secure Hash Algorithm 2) cryptographic hash function.
• the EzKey 10 is made in a way that it cannot be copied, or 'decoded'. The resilience of the EzKey 10 will be described later.
• the secret, unique number contained within the EzKey 10 cannot be extracted from it. This means that each individual EzKey 10 will give a different answer when asked to perform a hashing operation on the same username and password combination.
• UPH User Password Hash
• This UPH may be used as a cryptographic key to encrypt and/or decrypt a private key belonging to the user.
• the private key may be used for encryption or decryption of data, and may be any cryptographic key.
• the cryptographic key may be a secret key known only to the user, a shared secret key for encrypted communication with another party, or a private key from a public-private key pair.
• a useful function is to limit the number of answers the EzKey 10 can produce within a given period of time, for example no more than ten UPHs per second. This prevents 'brute force' attempts to produce vast amounts of data from the key, in an attempt to establish the pattern or behaviour of the hashing it carries out on various different password seeds.
• FIGS 2 and 3 illustrate how the UPH generated by the EzKey 10 may be used to permit the user to securely generate, store and access their private cryptographic keys.
• Figure 2 illustrates an exemplary process by which a new cryptographic profile may be generated, which will be described below.
• step 202 the user 1 enters their username and password into the
• a UPH is generated based on the username/password combination using the EzKey 10, as described above.
• a random Offset' value is generated. This offset value may be generated in any suitable manner, for example using a random number generator in the CSP or elsewhere in the computing device 20 or in the EzKey 10.
• the offset is applied to the UPH to generate an offset UPH (OUPH).
• UPH offset UPH
• the offset may be applied in any suitable manner that allows permutation of the UPH.
• the offset is a random number having the same binary length as the UPH and the offset is applied to the UPH using an XOR function.
• the CSP generates a cryptographic key to be associated with the cryptographic profile.
• this cryptographic key may be used for encryption or decryption of data.
• the cryptographic key may be a secret key known only to the user, a shared secret key for encrypted
• the CSP will also generate a corresponding public key, which may be presented to the user and/or stored locally and/or stored with the eventual cryptographic profile.
• the CSP then encrypts the cryptographic key using the OUPH as the encryption key.
• This generates a new Encrypted Private Key (EPK).
• the type of encryption used is preferably a symmetric encryption algorithm, for example AES, such that it can be reversed using the OUPH.
• the cryptographic key contained in this EPK can now only be obtained by the user whilst in possession of the EzKey 10 and their username/password.
• the CSP may then transmit the EPK to be stored a server 30 so that it can be retrieved by the user 1 when required.
• the EPK and offset are stored as a cryptographic profile belonging to the user.
• cryptographic profile may also store an identifier of the EzKey 10 associated with the offset, such as a serial number.
• this server 30 can be private, or even semi-public.
• the Encrypted Private Key may be stored on a (semi-)public server 30, which may be accessed via the user's private intranet or via the public internet 25. Since it is impossible for the hacker to obtain the UPH, the EPK is useless to them. Because no human needs to 'remember' the cryptographic key, it can be 2000 to 3000 bits long or even more.
• the profile server 30 is operated by a profile service provider, which maintains the servers and allows the user to connect to their stored cryptographic profiles. For example, the user may be required to log onto the server when initialling the CSP on a new computing device 20.
• cryptographic profile is preferably stored on the profile server, it will be appreciated that additionally or alternatively, cryptographic profiles of the user may be stored locally on the computing device 20.
• the user 1 selects one of their cryptographic profiles to access.
• This step may be performed automatically by the CSP, for example it may know to retrieve a specific cryptographic profile responsive to an API call from a particular CUS program.
• the user may be presented with a list of available profiles (or a subset of profiles, for example that may be used for a particular application) from which to select the profile to be accessed.
• the CSP prompts the user 1 to enter their username and password.
• the CSP receives the username and password input by the user and securely transmits them to the EzKey 10.
• the EzKey 10 generates a UPH, as described above, based on the username/password combination and the secret number etched in the EzKey 10.
• the UPH is then securely transmitted back to the CSP on the computing device 20, where the CSP applies the offset at step 310 to generate an OUPH.
• the CSP will select the corresponding offset for the EzKey currently connected.
• the CSP retrieves the EPK from the cryptographic profile, and the OUPH is used as a decryption key at step 314 to decrypt the EPK.
• the CSP is then in possession of the user's unencrypted cryptographic key.
• the unencrypted cryptographic key is stored temporarily in memory on the user's device 20 (desktop computer, laptop, tablet, phone or suchlike). At this point the user 1 is in control of his own plaintext (unencrypted) private key and can be thought to have 'self-authenticated'. The user 1 may then use their cryptographic key as desired.
• the above methods are merely examples and that many permutations are possible within the scope of the present disclosure.
• any one or more processes performed by the CSP on the computing device 20 may be performed instead on the EzKey 10, such as steps 208/310.
• the order of steps is not limiting and the steps may be performed in any suitable order. For example, steps 206, 210, 304, 308, and 312 may be performed earlier in the process.
• Client Security Program is now in control of the plaintext private key.
• Client User Software operating on the computing device 20 can now perform acts including one or more of logon, secure email and file encryption transparently to the user.
• George 1 now wants to access his bank account. He goes through the 'self authentication' process above, and gets his plaintext Secret Key temporarily in the memory of his device 20. He then requests to log onto his bank account via the internet 25.
• the bank 40 offers him a challenge. However, instead of the challenge being 'what's your password' - and comparing his answer with a stored copy that the bank 40 has - it challenges him to show he has the secret key. For example, it may generate a message containing a random number or string. This will obviously be a different number every time, and such messages are referred to in cryptology as a NONCE. There are many ways known to do this. Typically this message will contain a random number that will be 256 bits or longer.
• the bank 40 will then encode this message using RSA cryptology or similar using a public key, which is widely available and associated with this user, and is of no use to anyone without the plaintext private key. So the bank uses the public key associated with George 1 to encode the message containing the random number or string. This results in a further long string, again typically 256 bits or longer. Using the unencrypted private key, which is still stored temporarily in memory in the user's local hardware, George 1 decrypts the string to revert back to the message containing the original random number.
• This message is then sent back to the bank.
• the bank 40 verifies that this is indeed the original message containing the random number (or NONCE) that they produced, and if it is, assume that George 1 is authenticated. At this point access is given to George's bank account.
• a further example may be where the user stores encrypted data files remotely, for example on a remote server 50, such as using cloud storage.
• the user may store the files in an encrypted form using the cryptographic key to encrypt and decrypt the files.
• the user can easily access both the key and the data at any location where they have their EzKey 10.
• the encrypted data stored on the remote sever 50 cannot be read, even should a third party obtain access to them.
• the user selects a cryptographic profile that they wish to add an additional EzKey 10 to.
• the user enters their username and password for a first EzKey 10, which is already associated with the cryptographic profile, and at step 406, the first EzKey 10 generates a first UPH for the username/password combination, which is returned to CSP.
• each EzKey has its own unique secret number, and so the two UPHs will be different from one another.
• the CSP retrieves the offset from the cryptographic profile associated with the first EzKey 10. Then, at step 412, compares the first offset, the first UPH and the second UPH to determine a second offset that, when applied to the second UPH, converts it to the decryption key. For example, where an XOR function is used to apply the offset, the second offset may be calculated by applying the XOR function to the first offset and the first UPH (to generate the decryption key), and then by applying the XOR function to the decryption key and to the second UPH.
• the second offset is transmitted by the CSP to the profile server.
• this permits two or more EzKeys to be permitted to decrypt a single cryptographic key. Consequently, if one EzKey 10 is lost, then the cryptographic keys can still be retrieved using the backup.
• Bluetooth® 4.2 which incorporates a security layer, preventing criminals who can get close enough to the Personal Access Network, to prevent them 'scanning' the contents of the Bluetooth transmission.
• Bluetooth® 4.2 is the most widely known. Its security incorporates 'channel hopping' during the transmissions, so that not only does a criminal have to try and decode the data on the link from a scanner that needs to be very close to the user, but he also needs to know which frequency channel to monitor and when.
• the cryptographic profile includes a single EPK and one or more offsets associated with respective EzKeys 10.
• the user may have multiple cryptographic profiles, with a separate EPK associated with each.
• a cryptographic profile may comprise multiple EPKs for different applications. If all EPKs in the cryptographic profile are encrypted using the same EzKeys 10 and username/password combination, then only a single offset is required for each EzKey 10 for all of the EPKs in the cryptographic profile.
• 'salt' may be used to increase security.
• a salt is random data that is used as an additional input to a one-way function that "hashes" a password.
• a salt may be added when the EzKey 10 generates the UPH such that, even if the same password is used for different EPKs, the UPH will be different and so an individual UPH can only decrypt the corresponding EPK(s). In this case, a salt would be stored alongside the offset for the respective EPK(s).
• username/password combination to generate the UPH
• a separate username and password are not inherently required.
• the system could be implemented using just a password, or some other type of reproducible data, such as data derived from a biometric identifier of the user.
• the username and password are entered via the computing device 20 running the CSP in this embodiment, it is possible that they could be entered directly into the EzKey 10 by the user, for example via an onboard keypad or biometric sensor.
• the EzKey 10 is useless without the password.
• the encrypted private key is useless without the means to decode it.
• a further advantage is that banks and other institutes or service providers no longer have to keep sensitive information, like password copies or hashed password copies on their servers.
• PKI Public Key Infrastructure
• PKI certificates are well known, and described in many places.
• the Username/password pair is in practice a concatenation combination of two strings; the distinction is only useful to suit the user's mental model: a user could own/control many different identities, each one with a different username and the same password, or each one with a different password.
• the password can be 'blank' when the username is locally unique (i.e. unique on the EzKey 10 used)
• the username, the password, or the username/password combination can be replaced by a biometric
• the Client User Software can be any type of program, including an app for mobile devices.
• a user can have/own/control as many identities as they like.
• the user's local hardware 20 can be a desktop computer, laptop, mobile, wearable, or any other computing device.
• a profile may hold additional information, like the user's real name, address, pictures and so on.
• More than one combination of password and EzKey 10 can be allowed to unlock the encrypted secret key
• the first element is the user 1 , his simple memorable password, and his interface device 20 (Desktop computer, Laptop, tablet, phone or similar)
• the second is the EzKey 10
• the third is a publically, semi publically, or privately available profile containing the user's encrypted private key.
• the EzKey 10 is described as a 'local' device. However, it will be appreciated that the EzKey 10 need only be 'local' from a security of view. That is to say, the EzKey 10 needs to be completely under the control of the user 1 , e.g. 'owned' by the user 1 and by the user 1 alone, as opposed to being controlled by a separate organisation, such as a bank 40 or similar.
• the EzKey 10 may not necessarily be located in physical proximity to the user 1 at the time of use.
• communication with the EzKey 10 via communications link 15 should meet the following three criteria to provide good security: 1.
• the communication between the EzKey 10 and the CSP running on the user terminal 20 is private.
• the user 1 or the CSP is able to verify that the EzKey 10 being
• TLS Transport Layer Security
• the definition of the physical integrity of the EzKey 10 depends on the specifics of the EzKey 10 implementation, as well on the circumstances and requirements of the user 10. For example, the user 1 may wish to be alerted as soon as the security of the physical location where the EzKey 10 is located is breached, or perhaps when the EzKey 10 is moved outside of a certain physical range. In some embodiments, the EzKey 10 can send an alert when its own physical integrity is compromised. There are many possibilities.
• the response to a breach of integrity is also up to the user 1.
• the user 1 may simply be warned.
• the associated Private Keys, other temporary data stored by the EzKey 10 and CSP are immediately and automatically revoked and all their identities and authorizations dropped, or suspended.
• the EzKey 10 can be physically located in a secure environment, possibly under the control of a trusted third party. In many cases it would be sufficient to store the EzKey 10 in a safe place, i.e. other than the site of the user terminal 20, which may be in the office or home of the user 1. One possible proposition is to have the EzKey 10 physically stored in a data centre, along with many others.
• the EzKey 10 could be a virtual device stored in a cloud, e.g. a generic container would be loaded with a specific virtual EzKey 10 implementation, completely under the control of the user 1.
• a large number of virtual EzKeys 10 would anonymize each individual virtual device, by making it difficult to associate it with their user or users.
• Both the container and the container's hypervisor could be a weak spot in such a system, but that may be perfectly acceptable, depending on their construction, and on the circumstances and requirements of the user 1.

Landscapes

• Engineering & Computer Science (AREA)
• Computer Security & Cryptography (AREA)
• Computer Networks & Wireless Communication (AREA)
• Signal Processing (AREA)
• Computer Hardware Design (AREA)
• Computing Systems (AREA)
• General Engineering & Computer Science (AREA)
• Health & Medical Sciences (AREA)
• Biomedical Technology (AREA)
• General Health & Medical Sciences (AREA)
• Storage Device Security (AREA)

Applications Claiming Priority (2)

Publications (1)

Family

ID=58462873

Family Applications (1)

Country Status (3)

Families Citing this family (1)

Family Cites Families (2)

• 2017
  • 2017-02-01 GB GBGB1701645.2A patent/GB201701645D0/en not_active Ceased
• 2018
  • 2018-01-31 WO PCT/IB2018/050587 patent/WO2018142291A1/en unknown
  • 2018-01-31 EP EP18705732.8A patent/EP3577849A1/de not_active Withdrawn

Also Published As

Similar Documents

Legal Events