+

WO2018172782A1 - Justificatifs d'identité de sécurité - Google Patents

Justificatifs d'identité de sécurité Download PDF

Info

Publication number
WO2018172782A1
WO2018172782A1 PCT/GB2018/050758 GB2018050758W WO2018172782A1 WO 2018172782 A1 WO2018172782 A1 WO 2018172782A1 GB 2018050758 W GB2018050758 W GB 2018050758W WO 2018172782 A1 WO2018172782 A1 WO 2018172782A1
Authority
WO
WIPO (PCT)
Prior art keywords
key
feature
values
polynomial
enhanced
Prior art date
Application number
PCT/GB2018/050758
Other languages
English (en)
Inventor
William Gareth James Howells
Klaus Dieter Mcdonald-Maier
Original Assignee
Metrarc Limited
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Priority claimed from GBGB1704746.5A external-priority patent/GB201704746D0/en
Priority claimed from GBGB1704744.0A external-priority patent/GB201704744D0/en
Priority claimed from GBGB1704743.2A external-priority patent/GB201704743D0/en
Priority claimed from GBGB1704742.4A external-priority patent/GB201704742D0/en
Application filed by Metrarc Limited filed Critical Metrarc Limited
Priority to US16/497,311 priority Critical patent/US11133930B2/en
Priority to GB1913273.7A priority patent/GB2574545A/en
Publication of WO2018172782A1 publication Critical patent/WO2018172782A1/fr

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/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/30—Public key, i.e. encryption algorithm being computationally infeasible to invert or user's encryption keys not requiring secrecy
    • H04L9/3006—Public key, i.e. encryption algorithm being computationally infeasible to invert or user's encryption keys not requiring secrecy underlying computational problems or public-key parameters
    • H04L9/302—Public key, i.e. encryption algorithm being computationally infeasible to invert or user's encryption keys not requiring secrecy underlying computational problems or public-key parameters involving the integer factorization problem, e.g. RSA or quadratic sieve [QS] schemes
    • 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/30—Public key, i.e. encryption algorithm being computationally infeasible to invert or user's encryption keys not requiring secrecy
    • H04L9/3066—Public key, i.e. encryption algorithm being computationally infeasible to invert or user's encryption keys not requiring secrecy involving algebraic varieties, e.g. elliptic or hyper-elliptic curves

Definitions

  • the present invention relates to security credentials. BACKGROUND
  • a method for generating an encryption key for use in an encryption process at a device comprising measuring respective values of a plurality of features of the device to generate a plurality of feature values, normalising the feature values using a respective normalisation map for each feature to generate a plurality of normalised values, and generating the encryption key in dependence on the normalised values.
  • the method comprises modifying the measured values of the plurality of features to generate a plurality of modified values, and using the modified values as the feature values.
  • modifying the measured values comprises performing one or more of a mask operation and a bit-shift operation on the measured values.
  • the mask operation comprises applying one or more of a bitwise XOR mask and a bitwise XNOR mask to at least one predetermined bit.
  • the method comprises calibrating the feature values in advance of generating the encryption key by determining a plurality of calibration values for each of the plurality of features of the device, generating a distribution of calibration values for each feature, normalising each distribution, and generating the respective normalisation map for each feature in dependence on the normalised distributions.
  • Suitably calibrating the feature values comprises determining the plurality of calibration values for at least one feature at a plurality of devices.
  • the distribution comprises the frequency of occurrence of each calibration value.
  • Suitably normalising the distribution comprises associating a calibration value of a particular feature to a predetermined value.
  • Suitably normalising the distribution comprises associating a set of calibration values of the particular feature to the predetermined value.
  • the set is a range of calibration values.
  • each calibration value comprises a word of a predetermined size.
  • the predetermined value comprises a word of a predetermined size.
  • the method comprises generating the encryption key using a key generation algorithm which combines the normalised values.
  • the normalised values comprise words of a predetermined size.
  • the method comprises dividing the encryption key to form an asymmetric key pair, and using the asymmetric key pair to provide a digital signature.
  • the plurality of features comprises one or more hardware feature and/or one or more software feature.
  • the plurality of features comprise an indication of one or more of network connectivity of the device, network activity of the device, VOIP activity of the device, location service activity of the device, a MAC address and/or a serial number of the device, the number and/or identity of open ports of the device, the number and/or identity of active processes of the device, disk performance during one or both of a read operation and a write operation, an amount of free and/or active RAM at the device, the number and/or identity of one or more hardware components of the device, a device-specific bias associated with an embedded system at the device, a temperature of a hardware component of the device, a power state of the device, a sensor of the device and/or an output of the sensor, a data and/or a media file at the device, a contact list at the device, how the device is accessed, telephony codes used by the device, and an attribute of a container at the device, the
  • the indication of network connectivity comprises an indication of one or more of: whether the device is connected to a network, a measure of performance of a network connection, whether the network connection is over a WAN and/or a LAN, whether the network connection is over one or more of a cellular connection, a Wi-Fi connection, a Bluetooth connection, a NFC connection, a network identifier, an IP address of the device.
  • the indication of the network identifier comprises a subset of the characters of the network identifier.
  • the indication of whether the device is connected to a network comprises a Boolean value, and/or one of a "connected” state, a “connecting” state, a “disconnecting” state and a "communicating” state.
  • the indication of network activity of the device comprises a measure of data served and/or consumed by the device.
  • the indication of location service activity of the device comprises an indication of one or both of the latitude of the device and the longitude of the device.
  • the indication of the power state of the device comprises an indication of the battery level, a time since last charge, a frequency of charging over a predetermined charging time period, an average battery level over a predetermined usage time period, an indication of whether the battery is charging, and/or an indication of whether the battery is connected to a power source.
  • the encryption key is used in an RSA algorithm
  • the method comprises determining whether the encryption key is co-prime with the number of totatives of the RSA algorithm, and if so using the encryption key as the private key in the RSA algorithm, otherwise determining the result of an offset function of the encryption key, where an offset is selected so that the result of the offset function is co-prime with the number of totatives of the RSA algorithm, and using the result of the offset function as the private key of the RSA algorithm.
  • the encryption key is used in an elliptic curve cryptographic algorithm, wherein parameters of the elliptic curve algorithm comprise a base point G of the elliptic curve and a multiplicative order n of the base point, the method comprising determining whether the encryption key is within [1 , n-1 ], and if so using the encryption key as the private key of the elliptic curve algorithm, otherwise applying a modulo-operation to the encryption key with n as the modulus to obtain the private key.
  • a method for securely processing a private key at a device comprising receiving a private key at the device, receiving an encryption key generated as described herein; combining the encryption key with the private key using a combination function to generate an enhanced key, and storing the enhanced key.
  • a combination function comprises a XOR function.
  • the enhanced key is combined with a symmetric blockcypher algorithm to generate a modified enhanced key.
  • a method for securely processing a private key at a device comprising receiving an encryption key generated as described herein, combining the encryption key with the enhanced key generated as described herein, wherein the encryption key and the enhanced key are combined using a combination function to thereby retrieve the private key.
  • a new enhanced key is generated in dependence on the previous enhanced key.
  • a system for generating an encryption key for use in an encryption process at a device comprising a processor configured to measure respective values of a plurality of features of the device to generate a plurality of feature values, normalise the feature values using a respective normalisation map for each feature to generate a plurality of normalised values, and generate the encryption key in dependence on the normalised values.
  • a method for generating an enhanced security credential at a device comprising receiving a first security credential at the device, determining a second security credential in dependence on one or more feature of the device, combining the first security credential and the second security credential to form the enhanced security credential, and outputting the enhanced security credential.
  • the first security credential is a user password.
  • the enhanced security credential is output in response to receiving the first security credential.
  • Suitably only the enhanced security credential is output from the device.
  • the enhanced security credential is output to a keyboard buffer.
  • the second security credential is determined by measuring respective values of a plurality of features of the device to generate a plurality of feature values, normalising the feature values using a respective normalisation map for each feature to generate a plurality of normalised values, and generating the second security credential in dependence on the normalised values.
  • the method comprises determining whether each character of the enhanced security credential satisfies a set of requirements for the enhanced security credential, and modifying each character to satisfy the set of requirements in dependence on the determination.
  • the set of requirements identifies a set of valid characters, and the step of determining whether each character satisfies the set of requirements comprises determining whether each character of the enhanced security credential is identified in the set of valid characters, and modifying each character in dependence on that determination.
  • the set of requirements identifies a number of required characters from two or more sets of characters
  • the method comprises determining whether the characters of the enhanced security credential satisfy the required number of characters from each set of characters, and in dependence on the determination, selecting a character of the enhanced security credential and modifying the character to be a member of one of the sets of characters.
  • modifying a character of the enhanced security credential comprises taking the value of the character modulo the valid range of character values and adding a minimum valid character value to the result.
  • a system for generating an enhanced security credential at a device comprising a processor configured to receive a first security credential at the device, determine a second security credential in dependence on one or more feature of the device, combine the first security credential and the second security credential to form the enhanced security credential, and output the enhanced security credential.
  • a method for processing a secure key at a device in dependence on a plurality of security credentials comprising determining a tolerance value indicating the number of security credentials required to process the secure key, determining coefficients of a polynomial of an order that is one less than the tolerance value, the secure key being a function of the polynomial, determining a plurality of security credentials in dependence on one or more feature of the device, the number of security credentials being equal to or greater than the tolerance value, using each security credential as a first parameter of the polynomial to generate a set of corresponding second parameter values, and storing the set of second parameter values and a value indicating the order of the polynomial.
  • the function of the polynomial comprises a value of the polynomial at a pre-determined location.
  • the function of the polynomial comprises the -intercept of the polynomial.
  • each security credential is used as an x-value of the polynomial and the second parameter values comprise y-values.
  • the security credentials and the polynomial are discarded in dependence on storing the set of second parameter values and the value indicating the order of the polynomial.
  • a method for processing a secure key at a device in dependence on a plurality of security credentials comprising (a) determining a plurality of security credentials in dependence on one or more feature of the device, (b) reading a stored set of parameter values and a stored value indicating an order of a polynomial, (c) determining coordinates from respective ones of the security credentials and respective ones of the parameter values, (d) using at least a subset of the determined coordinates to determine coefficients of a polynomial with an order indicated by the stored value, (e) determining a
  • predetermined function of the polynomial (f) storing the predetermined function as a possible secure key,(g) repeating steps (d) to (f) for all the subsets of coordinates to determine a set of possible secure keys, (h) verifying whether the set of possible secure keys comprises the secure key.
  • the stored set of parameter values and the stored value indicating an order of a polynomial are generated as described herein.
  • the verifying step comprises attempting to decrypt a message previously encrypted by the secure key with each of the possible secure keys, wherein the possible secure key that successfully decrypts the message is determined to be the secure key.
  • the retrieved secure key is used to access a secured system at the device.
  • the method comprises determining that the verification is unsuccessful, and in dependence on that determination (i) using a subset of the generated coordinates to determine coefficients of a reduced-order polynomial with an order reduced by an integer compared to the polynomial of step (d), (j) determining a predetermined function of the reduced-order polynomial, (k) storing the predetermined function of the reduced- order polynomial as a possible alternative key, (I) repeating steps (i) to (k) for all the subsets of coordinates to determine a set of possible alternative keys, (m) verifying whether the set of possible alternative keys comprises an alternative key of a set of alternative keys by attempting to decrypt a message previously encrypted by each of the set of alternative keys with each of the possible alternative keys, wherein the possible alternative key that successfully decrypts the message is determined to be the alternative key.
  • the method comprises granting a level of security access at the device in dependence on the integer which results in the retrieval of the alternative key.
  • features of the device are grouped into a feature set, and a security credential is determined in dependence on the feature set.
  • a feature set comprises related features of the device.
  • a weighting is applied to a set to form a weighted set, and the security credential is determined in dependence on the weighted set.
  • the method comprises determining that one of the secure key and the alternative key is successfully verified, identifying that a security credential is outside a range of valid values for the security credential, and modifying a mapping relating to the security credential such that the security credential is mapped by the modified mapping to be within the range of valid values.
  • the mapping is performed in dependence on a
  • the modified mapping permits the security credential to generate a valid point on at least one of the polynomial and the reduced-order polynomial.
  • one or more security credential corresponds to a device of a plurality of devices.
  • one of the plurality of devices requests an identifier from a new device, and the identifier is used to produce a coordinate pair on at least one of the polynomial and the reduced-order polynomial, such that the new device is able to retrieve one or more of the secure key and the alternative key.
  • a system for processing a secure key at a device in dependence on a plurality of security credentials comprising a processor configured to (a) determine a plurality of security credentials in dependence on one or more feature of the device, (b) read a stored set of parameter values and a stored value indicating an order of a polynomial, (c) determine coordinates from respective ones of the security credentials and respective ones of the parameter values, (d) use at least a subset of the determined coordinates to determine coefficients of a polynomial with an order indicated by the stored value, (e) determine a predetermined function of the polynomial, (f) store the predetermined function as a possible secure key, (g) repeat (d) to (f) for all the subsets of coordinates to determine a set of possible secure keys, and (h) verify whether the set of possible secure keys comprises the secure key.
  • a method for entropy smoothing in an encryption key generation process at a device comprising determining a plurality of security credentials in dependence on one or more feature of the device, determining a correlation between two of the plurality of security credentials, determining probability distributions of the security credentials and of the correlated security credentials, and in dependence on a comparison of the probability distributions, generating the encryption key using one or more of the plurality of security credentials and the correlation to thereby reduce probability variations in the generation of the encryption key.
  • the method comprises determining a correlation coefficient of the correlation, in which the encryption key is generated by using the correlation coefficient as well as or in place of the correlated security credentials.
  • the encryption key is generated by combining two of the plurality of security credentials using a predetermined weight matrix.
  • generation of the encryption key is performed using an entropy smoothing algorithm.
  • the method comprises determining the variance of the correlation coefficient for a range of security credentials, and generating the encryption key in dependence on the variance.
  • the range of security credentials comprises security credentials determined from a plurality of devices and/or from a plurality of determination steps at one device.
  • generation of the encryption key is performed using the entropy smoothing algorithm in dependence on the variance.
  • a method for securely processing a private key at a device comprising receiving a private key at the device, receiving an encryption key generated as described herein; combining the encryption key with the private key using a combination function to generate an enhanced key, and storing the enhanced key.
  • the combination function comprises a XOR function.
  • the enhanced key is combined with a symmetric blockcypher algorithm to generate a modified enhanced key.
  • a method for securely processing a private key at a device comprising receiving an encryption key generated as described herein, and combining the encryption key with the enhanced key generated as described herein, wherein the encryption key and the enhanced key are combined using a combination function to thereby retrieve the private key.
  • a new enhanced key is generated in dependence on the previous enhanced key.
  • a system for entropy smoothing in an encryption key generation process at a device comprising a processor configured to determine a plurality of security credentials in dependence on one or more feature of the device, determine a correlation between two of the plurality of security credentials, determine probability distributions of the security credentials and of the correlated security credentials, and in dependence on a comparison of the probability distributions, generate the encryption key using one or more of the plurality of security credentials and the correlation to thereby reduce probability variations in the generation of the encryption key.
  • a non-transitory computer-readable storage medium having stored thereon computer-readable instructions that, when executed at a computer system, cause the computer system to perform a method as described herein.
  • Any one or more feature of any aspect above may be combined with any one or more feature of any other aspect above.
  • Any apparatus feature may be rewritten as a method feature, with the necessary changes being made in the wording. These have not been written out in full here merely for the sake of brevity.
  • figure 1 illustrates stages in a key generation process
  • figure 2A illustrates a series of steps in a calibration phase of a key generation process
  • figure 2B illustrates a series of steps in an operation phase of a key generation process
  • figure 3 shows a chart illustrating mapping various ranges of free RAM in a system to values
  • figure 4 illustrates two key generation processes
  • figure 5 illustrates forming an enhanced password at a device
  • figure 6 illustrates modifying a password at a device to satisfy password requirements
  • figure 7A illustrates an example of a browser on a mobile device
  • FIGS. 7B and 7C illustrate accessing a password enhancer app extension at mobile devices
  • FIGS. 7D and 7E illustrate a password enhancer app extension at mobile devices
  • FIGS. 7F and 7G illustrate populating a password field in a webpage at mobile devices using the password enhancer app of figures 7D and 7E;
  • figure 8 illustrates correlation patterns for different mobile devices
  • figure 9 illustrates forming an enhanced key from a private key at a device
  • figure 10 illustrates retrieving a private key from the enhanced key of figure 9;
  • figure 1 1 illustrates an example polynomial showing the y-intercept
  • figure 12 illustrates an example category of features
  • figure 13 illustrates another example category of features
  • figure 14 illustrates another example category of features
  • figure 15 illustrates another example category of features
  • figure 16 illustrates another example category of features
  • figure 17 illustrates entropy smoothing as part of forming an enhanced password at a device.
  • the present techniques represent an exciting new approach for generating unique identifiers for embedded devices.
  • This approach can enable secure encrypted communication between devices, which can potentially significantly reduce both fraudulent activity, such as eavesdropping, and device cloning.
  • data encryption techniques are now highly sophisticated and well established, encryption itself cannot necessarily protect against fraudulent data manipulation when the security of encryption keys cannot be absolutely guaranteed.
  • the use of authentication as discussed herein represents a novel concept of regulating access to devices and is aimed at providing protection at the especially vulnerable points where data access is initiated.
  • ICMetrics possess the following significant potential:
  • ⁇ tampering with the constitution of a circuit will cause its behaviour to change, potentially causing the features underlying the ICMetric to change, perhaps dramatically, thus causing the generated ICMetric to change. Consequently, a faulty or maliciously tampered device will be autonomously prevented from decrypting its own stored data or participating in any initiated secure communications, as the regenerated keys will differ from those created before its integrity was compromised. I.e. the ICMetrics approach can be made to fail securely and provide a very high immunity from cloning and tampering.
  • ICMetrics is a revolutionary new Trusted Computing approach that avoids storage of root-of-trust encryption keys by creating them on demand based on measurable properties and features of the computer system itself. ICMetrics may be considered as the computer equivalent of biometrics. However, unlike traditional biometrics, unique templates are not needed to create the final encryption key, so the approach is significantly more secure than conventional encryption techniques, including those incorporating biometrics.
  • the Template-Free technique employed by ICMetrics uses a novel normalisation and combination strategy to merge a series of metrics, which suitably represent one or more of the properties, features and behavioural characteristics of a computer, device or service, into a single all-encompassing value, which is the system's ICMetric.
  • the ICMetric architecture has three stages as shown in Figure 1 .
  • the component metrics are obtained using a monitoring infrastructure 102 that suitably employs a novel architecture in order to efficiently characterise the computer's behaviour while it operates normally.
  • optimised pre-processing occurs in stage two 104, which extracts raw property and feature values and provides a consistent data format ready for final processing.
  • custom normalisation and trimming techniques are employed to maximize the ICMetric's permutations and therefore security.
  • the combination strategy employs advanced pattern recognition techniques that are generic to instances of a computer design, rather than individual templates; therefore it is infeasible to recreate the ICMetric for a specific computer or electronic device, without first capturing all of its many sample values that are only in existence when encryption is needed.
  • the primary purpose of the technology is thus to encrypt components of devices, systems or services using properties, or features, derived from their own construction and behaviour to form a digital signature capable of assuring both their authenticity and freedom from malware whilst simultaneously allowing the flexibility for them to operate within their designed specification and to execute on an arbitrary (i.e. any desired) platform.
  • the ability to securely access services located online from a mobile device offers significant advantages for ease of provision and access to both existing and bespoke network-based services.
  • such technology also presents significant challenges in assuring that the service accessed is authentic and free from any form of malware.
  • the need to protect the integrity of each service has long been recognised, but the increasingly widespread adoption of network-based services raises new challenges, particularly where these services are communicating
  • the measured features need not remain absolutely constant but are free to vary, for example within deduced parameters.
  • the proposed ICMetric-based system is a two-phase system.
  • the system comprises a calibration phase and an operation phase.
  • Each phase may operate as follows.
  • normalisation maps for each feature. These normalisation maps suitably relate the range of measured values for a given feature (such as a software system) to a fixed range of values chosen for that particular feature. The absolute values of features can thus be discarded, and abstract virtual values may suitably be chosen in their place. Operation phase (this phase is suitably applied each time an encryption key is desired for a given circuit) 1. Measure features for the given software and/or hardware system for which a digital signature (or an encryption key) is desired.
  • asymmetric key pair Divide the basis key to form an asymmetric key pair (several techniques are possible to do this, as will be appreciated by the skilled person) which may then be employed to provide a digital signature for the service in question. This is suitably done by encrypting a digest of component data of the service. Alternatively or additionally the asymmetric key pair may be employed for secure communications in conjunction with the asymmetric key pair associated with another service.
  • the ICMetric system may be used in conjunction with a range of encryption algorithms. It is suitably independent of any particular encryption algorithm.
  • Figure 2A illustrates the calibration phase. In this phase, samples are obtained from multiple users 202. Features are extracted from the samples 204. Feature values are then normalised 206. One or more mean and co-variance is calculated 208. Decorrelated values are then calculated for each feature 210. Left and right margins of bits to discard from the result are calculated 212. This latter step can aid in obfuscating the result, i.e. it will restrict the ability of an observer to recreate the value from which the result was obtained, or even to guess what feature the value relates to.
  • Figure 2B illustrates the operation phase. In this phase, samples are obtained from an individual user 220. Features are extracted from the sample 222 and normalised 224. Means and co-variances are calculated 226. A decorrelated value is calculated for each feature 228. Feature values are quantized 230. Decorrelated values are combined to derive a code 232.
  • Device features may suitably be any one or more of the various characteristics of a specific device that can be used to differentiate it from other devices. They come in many forms, from specific hardware details to the habits of a device's user. These will be described in more detail below.
  • Device features play an important role in the present approach to creating secure encryption keys. When current systems encrypt data, they must create and store templates of the generated encryption keys in order to decrypt the data at a later date. The use of device features as in the present approach extricates the encryption process from any need to store such templates. This can reduce or eliminate one of the largest problems in current systems.
  • the system's strength lies primarily on the selection of robust and diverse features. There are certain aspects of each feature that need to be considered in order to determine its adequacy. Firstly, features should be able to achieve a certain level of obfuscation, either innately or by conducting certain procedures on them. Suitably the core components that make up the key are as obscure as possible from potential hackers. This is because if even just a few features remain completely obscure, the key becomes almost impossible to fraudulently replicate.
  • ICMetric technology Another aspect of ICMetric technology is that many features may produce values that are non-static, i.e. they may fluctuate as the device is used. An example of such a feature would be the current free RAM on the device.
  • FIG. 3 shows a chart illustrating various ranges of free RAM. At any one given time the device's current free RAM will reside somewhere along the axis 302 but will periodically move up and down. On its own this feature is likely to be too volatile to record over time. However it can be managed if ranges of values are created, which may be, for example as illustrated in figure 3, ranges of 400MB. Differently-sized ranges may be used in some implementations. Each of these ranges 304 is mapped to an arbitrary value 306.
  • Modern devices such as mobile devices are very sophisticated communication devices. They can permit powerful aggregation of data collected from their many sensors. Such devices typically comprise many different hardware elements designed for networking. This can permit a variety of features to be used for the ICMetric. For example, network data should be accessible. This can be useful even if some features may not individually have a particularly large entropy.
  • a device may be determined if a device is connected to a network such as the Internet, for example either via cellular and/or Wi-Fi. This is likely to be easy to access at the device as it is common practice to defensively code by checking for an Internet connection when a task is dependent on the presence of such a connection. This feature could be represented using a Boolean value to signify true and false, i.e. whether the device is connected or not. Is the device connected to Wi-Fi?
  • This feature is similar to the check for Internet connectivity. This feature can distinguish between one device connected to the Internet through a cellular connection, such as LTE or 4G, and another device connected via Wi- Fi. This feature does not require internet connectivity to succeed. Where one feature is searching for a WAN, the other is searching for a wireless LAN. Like the Internet connectivity feature, the result is expected to be a Boolean value. In general, the feature may search for, and optionally distinguish between, one or more wireless and/or wired connection.
  • the network name for example a wireless network SSID
  • a wireless network SSID is a feature that is likely to be accessible through the network interface. Unlike the connectivity features already identified, this feature is not expected to use an asynchronous call back design for accessing the information. It is expected to be accessible using a public API which will offer similar information to the Wi-Fi connectivity feature, but with increased entropy and inter-sample variance. For example, a predetermined number of characters of the name may be utilised, for example the first 7 characters of the name. Each character may be converted to a 1 -byte ASCII value and concatenated.
  • Bluetooth Another form of device communication is through Bluetooth. This is commonly found in modern mobile devices which makes it a good potential feature.
  • An obvious test to is try and determine the Bluetooth state of the device, for example whether it is active or inactive. A subset these states may be determined, such as “connected”, “connecting”, “disconnecting”, and “communicating”.
  • the Bluetooth technology is assessed, for example to determine the Bluetooth version, and/or, if version 4 or higher is detected, if it implements Bluetooth LE (low energy).
  • Another test would be attempting to measure the performance of the Bluetooth technology. This suitably comprises looking at the data, and the time it takes to measure, with the potential battery drain impacting the practicality of using some or all of these values as features, and the challenge in generating the value on demand. This feature may utilise callback functions when accessing the data.
  • This feature comprises the amount of network traffic the device serves and/or consumes.
  • the feature suitably comprises some context data like a timestamp or similar. Before reading the data it may not be known if this context data exists, or if there is just a large value signifying the amount of network data sent and/or consumed for an arbitrary duration.
  • the representation of the data is suitably also considered. If the data representation is, for example, an unsigned 32-bit integer then the value would overflow at approximately 4GB, which could be an entirely feasible limit to hit.
  • a data representation is selected in dependence on expected data sizes to reduce the effect of data overflows. This can help make this feature more stable, and more suitable for use in the ICMetric system.
  • This feature is intended to be handled in much the same way as the Bluetooth testing. Both are short-range communication protocols and so can be treated in much the same way.
  • determining if NFC technology is present on the device and active, or if it is not active (or not on the device) are the two Boolean values to test looking at. If it is present, it can be determined if NFC-powered technology like Beam is present. It may also be possible to measure the performance. It is worth noting that a lot of older devices such as iPhones are not believed to have the capability to use NFC. This itself may be a way to distinguish some devices.
  • a mobile device can now offer.
  • Most devices house advanced geo-location features, for example accelerometer sensors and/or GPS hardware. One or more of these features are suitably tested. This can complement network connectivity features, such as by looking at correlations like the location of the device and the wireless network SSID. With a lot of service permissions being coupled with the usage of various sensors, and sensors being such a big part of the modern mobile device, these are a group of features that should be readily accessible and potentially offer some very interesting features and combinations of features. Callback functions are also a common implementation when using services like GPS.
  • This feature involves testing to see if the location services on a device are active or not. This suitably provides a Boolean value as a result. This is relatively simple to implement as it would be common to code defensively to test for this condition before attempting to call code to perform a task which requires the location services to be active. Like any feature expected to be a Boolean value, the entropy is not going to be large. This feature may offer more possibilities when correlated with other features.
  • Attempting to access the position, such as the longitude and latitude, of a device permits testing to see if the value can be accessed, and/or the time it takes to get a value, the accuracy of the value, and/or the sensitivity of the sensors used.
  • An implementation using this feature is likely to need to register for notifications to updates to position. This may lead to authentication delays, which are undesirable in many situations (for example when a user is waiting for authentication to occur). The delay could be more significant if there is some caching involved in the process and requires some level of movement to get correct values. Longitude and latitude values may fluctuate without the device moving, which is a potential issue, depending on the accuracy of the values used for this feature. The values are generally very sensitive and will likely require a great deal of care handling and mapping them.
  • the values may be truncated to remove some of the precision, and/or measured as a form of distance from an arbitrary point using a formula, like Haversine. Further, there is the potential for significant battery drain on the device if this value is used as part of the ICMetric system and key generation demanded frequently. The battery power level may also therefore need to be considered. In one implementation approximate location details and geofencing are utilised.
  • This feature refers to attempting to reference a list of open ports on the device. There is some uncertainty if there will be much inter-sample variance if users cannot open ports manually, similar to how they can open them on computers using a firewall. There are also generally fewer services running on devices like tablet computers such as iPads and there may be fewer ports open than on a traditional computer. This is another feature that may not always be accessible.
  • the IP address is a feature that could be tightly coupled to the Wi-Fi name feature. It is expected to use the local address when connected to Wi-Fi and so should offer better inter-sample variance whilst having a similar intra- sample variance. In regards to accessibility, it is expected to be as protected as the Wi-Fi name feature, whilst also sharing the implementation techniques. Testing will simply be attempting to read the current IP address. In one example, the decimal points may be removed to take the address as one whole value. This value may then be obfuscated and mapped.
  • Memory and active processes can be very volatile and could be difficult to map individually but that also means it is likely to possess a strong entropy and have a potentially high inter-sample variance, both of which are desirable qualities for a candidate feature. Testing values for memory and processes may reveal useful correlated values which are expected to be naturally highly obfuscated and difficult to spoof.
  • Another strong case for using features like these in an ICMetric system is the ability to offer an early warning of potential malware in the system when the normal operating parameters vary beyond an acceptable level.
  • Memory is a feature that is expected to be very unpredictable but possess high entropy. It is not expected to cause accessibility problems as great as those as some other features (from the perspective of privacy). There may be, however, the challenge of finding the same memory values for different platforms. Wth so many different memory values prevalent in the system, initial testing will identify what memory values are actually accessible with public APIs. For example, Android is likely to reference the proc/meminfo structure, but that is not expected to be available on iOS, although it is likely that common memory values like active memory and free memory will be available for all platforms. Processes
  • Another feature is the performance of the disk when reading and writing. This feature can include how much data gets read and/or written for context in the measurement, but this could potentially be a feature value in itself.
  • the storage could be external or internal, and promising disk performance values for devices that can read and write different amounts depending on the active processes can offer features with high inter-sample variance, but are stable enough to exhibit low intra-sample variance. There might also be some interesting correlations between performance and system configurations represented by other features.
  • Containers can be used in systems to package together software such as a software application with the resources that it needs to run.
  • resources can include the code and any referenced libraries and/or tools, for example system libraries and/or tools.
  • the advantages of this approach are that the software can run consistently, independent of the environment in which it is to be run.
  • This approach implements an operating-system-level virtualisation scheme. This permits the provision of a plurality of instances, i.e. the containers, to be run, which can be isolated from one other.
  • An example of a type of container system is the Docker system.
  • Attributes of containers, and/or of container systems can be used in the present techniques.
  • CPU features, memory features, and/or network features can be used.
  • CPU features can provide information on the CPU statistics of the container, for example the Docker container.
  • Information can suitably be derived or obtained from, for example, one or more of cpu_stats/system_cpu_usage, cpu_stats/cpu_usage/percpu_usage/1 , and precpu_stats/system_cpu_usage.
  • Memory features can provide information on memory-related statistics of the container, for example the Docker container. Information can suitably be derived or obtained from, for example, one or more of
  • memory_stats/max_usage memory_stats/stats/active_file, memory_stats/stats/6_inactive_file, and
  • Network-related statistics can be revealed from, for example, the networks category of data obtainable from containers such as Docker containers. Information can suitably be derived or obtained from, for example, one or more of networks/ethO/rx_bytes, networks/ethO/tx_packets, and network settings/sandboxed. Hardware
  • the modern mobile device is made up of various hardware components, and properties of these components are expected to remain consistent for a long period of time.
  • mass-produced hardware is never made identical, and low-level metrics can have the possibility of identifying distinctions between their builds.
  • Over a combination of a number of hardware features it is expected that high inter-sample variance may be exhibited, with the consistency offered by hardware components allowing for low intra-sample variance.
  • Hardware features are not as susceptible to user interference and, with the hardware components effectively making up the device, can be said to have a strong association with a device. A lot of devices share similar hardware but the accessibility could be quite difficult.
  • This feature suitably refers to the battery of the device. There is a possibility that this feature value could appear arbitrary and take any form between empty (0) and full (1) at any time.
  • This feature suitably is able to identify information like which users regularly charge devices or devices which don't operate under heavy usage through values that do not drop below a certain threshold.
  • Power data suitably helps to infer stress level on the device and potential heavy usage.
  • the battery charge and discharge profiles are potential features that are accessible. This can be tested by reading for a value to represent the power remaining in the device, or to read it a number of times to measure the amount used over a short period of time. For the latter to prove useful it is likely that the device would need to be under considerable stress, or that the granularity of the power measurement is small enough to detect changes that would otherwise be undetectable. If patterns are followed, like charging every night, then it might be possible to imply information like heavy usage in the morning but even if this was possible, the usefulness of this feature as a distinguishing feature is likely to be dependent on when a device key is requested.
  • Hardware temperature can change and as a general rule of thumb the higher the stress level, the warmer the hardware gets.
  • the efficiency of each individual battery coupled with the level of activity could possibly result in individual temperature profiles.
  • the status of a power source refers to whether it is charging, unplugged, or plugged in but not charging.
  • This feature involves testing for information relating, for example, to how old the battery is, and/or the amount of power it can produce on a full charge.
  • This feature can comprise estimated life-expectancy and (assuming a rechargeable battery) a number of recharges.
  • This feature may comprise an indication of the battery type.
  • Another potentially useful feature is based on the device sensors. Attempting to analyse the sensitivity and quality of individual sensors on the device can produce very promising features. It can be determined what sensors exist on the device, and what information is accessible for any sensor found on the device. This feature suitably comprises analysing what the sensor(s) produce.
  • One example is performing audio analysis on files created by using the microphone, like voice memos.
  • Another example is performing image analysis on files created by using the camera.
  • Another example is analysing the manufacturing-dependent bias on MEMS sensors such as accelerometers and gyroscopes.
  • Another potentially useful feature is an embedded system within a particular device, and/or an Internet of Things device feature.
  • Such device features can exhibit device-specific biases.
  • a device-specific bias can be exhibited in MEMS sensors. These biases can be used to identify individual sensors. This can apply to sensors including accelerometers, gyroscopes and other types of MEMS sensors. This is particularly useful where the device biases are device-specific, and are for example introduced during a manufacturing process and/or previous use of the device.
  • the device biases need not be unique to a particular device. The fewer the number of that type of device that exhibit the same device bias, the better this feature is likely to be in the implementations discussed herein.
  • random number generators such as true random number generators
  • semiconductor chips may result in a device-specific signature or bias that can be utilised as a feature.
  • Media files for example images and video files
  • a user stores on their device offers the opportunity to perform image and video data analysis on very different data that is not expected to change regularly. It is related and accessible to the device, but uses the fact that the data is defined by a unique user that allows it to exhibit small intra-sample variance but large inter-sample variance along with good entropy. As an example, the 5 oldest images and videos found on the device could be analysed. Analysis on images taken by the device offers the additional advantage of inferring information about the quality of the camera on the device as well. It is worth noting that there is expected to be a good deal of meta-information about the files without the need to perform any advanced analysis techniques as well, including information like the location an image was taken. Contacts
  • Useful features might be found when testing for the frequency or pattern (suitably including numeric and non- numeric codes) for either logging in, or simply accessing the device using the touchscreen.
  • This feature focusses on accessing data relating to phone calls made by the device, and general cellular information like SIM data.
  • Reading the cellular provider codes relating to SIM information is possible. These are expected to be static values. This is a feature that will likely exhibit a low intra-sample variance but is not expected to have a high inter-sample variance or particularly high entropy.
  • Calendar Read events, reminders and attendees.
  • Sensors Name, power, range type and resolution information for sensors present.
  • Wi-Fi - Status configuration and security of configured networks and currently active Wi-Fi network.
  • One of the first features investigated was an analysis of the code complexity. This involves evaluating the cost of the algorithm(s) used in the implementation, i.e. looking at the operations undertaken and the amount of looping needed to get a result, as well as parsing the source on the server to track how many different branches can be traversed. Even though both implementations for generating prime numbers in this example use the sieve technique, the additional optimisers that were not contained in the spoof code resulted in a difference of complexity between the two source files.
  • a further optimisation, in the authentic server, is made on the outer loop where it breaks out of the loop once the current prime for sieving is greater than the square root of 2500.
  • the actual instruction used to check if a value is prime, or if it should be removed from the container is also handled differently between the two implementations.
  • the genuine server simply counts along the array to sieve away any number divisible by the current prime until the maximum value, 2500 in this case, has been reached.
  • the spoof server checks against every value in the container that is larger than the current prime, determining if it needs to be removed by employing the expensive modulo operation (current prime % next value > prime in container), all the way until the end of the container is reached.
  • the main server only has to move position in the container to remove a non-prime value a total of 3956 times before sieving is complete, but the other PHP sieve implementation on the spoof server performs 496688 evaluations before it completes, and each evaluation is computationally more expensive than simply moving a number of positions along a container.
  • Generating an ICMetric key is a lightweight process that firstly involves the gathering of feature values from the device. The features are then combined into categories, which go through the normalisation algorithm. This suitably obfuscates and/or normalises the categories into words of a set length. The generated words are then used to produce an un-hashed ICMetric key via the secret sharing algorithm discussed in more detail below. The ICMetric key is then employed in any of the protocols outlined below. The algorithm takes into account the maximum error tolerance and, if the feature values that were measured meet the minimum tolerance, then the correct key will be regenerated.
  • Step 1 Define Feature Categories
  • Table 1 Feature Category 1
  • Category 1 (as shown in table 1) is related to a device's network configuration with the mobile country code and the mobile network code being used in combination to uniquely identify the device's carrier.
  • the mobile country code and the ISO country code are fully dependent on one another whereas the mobile country code and the mobile network code are independent.
  • Table 2 Feature Category 2 Category 2 (as shown in table 2) is related to the connectivity of a device and most of the features are a binomial value that dictates the states of the features. The practical entropy is mostly dependent on the knowledge of the Wi-Fi SSID that the device is connected to and although any possible SSID is available, common names are more likely to occur.
  • Category 3 (shown in table 3) is based on the contacts on the devices and randomly associated filters on the contacts. In the simple example above the contacts are filtered by the first letters of the first and second name of the contact.
  • Category 4 (shown in table 4) is based on the media that is saved on the device; which in this case is an arbitrary image. This category can be re-used with multiple images, in this example it is used twice as Category 4A and 4B, each based on a different image.
  • Step 3 Confusion / Byte jumbling
  • Step 4 Dynamic Masking through XOR Operations
  • Step 2 dynamic masking of the JUMBLED matrix was performed in this step. This was achieved by carrying out bitwise XOR operations on specific elements (bytes) of the JUMBLED matrix while using some particular elements (bytes) as mask. Mathematically, it may be written as:
  • Step 5 Dynamic Masking through XNOR Operations
  • Step 5 Similar to Step 5, we again performed dynamic masking of the DM1 matrix to achieve more data obfuscation. This was achieved by carrying out bitwise XNOR operations on specific elements (bytes) of the DM1 matrix while using some particular elements (bytes) as mask. This may be written mathematically as:
  • the mini-ICMetrics generated above are used to generate the ICMetric key.
  • the first time the code is generated is the calibration phase.
  • the tolerance in the number of mini-ICMetrics needed for subsequent generation of the ICMetric key can be selected.
  • the tolerance is selected to be three, meaning that at least three correct mini-ICMetrics (out of the five in this example) will be needed.
  • the second step requires a polynomial of degree (or order) one less than the tolerance; thus in this example a polynomial of order 2 is generated.
  • the following quadratic polynomial is securely randomly generated:
  • the C value in the polynomial is the Y-axis intercept and is used as the un-hashed ICMetric key. More generally the secure key is suitably a function of the polynomial, such as a function of the polynomial at a predetermined location. In one example the predetermined located can be where the polynomial crosses the Y-axis.
  • the category words are used as the function arguments.
  • the function outputs are the corresponding Y values for the inputs; these are stored on the device, whereas the polynomial and the category mini-ICMetrics need not be stored, and are suitably discarded, which can enhance data security.
  • the stored values on their own cannot be used to reproduce the ICMetric key as alone they cannot be used to interpolate a polynomial without a corresponding X coordinate.
  • the category mini-ICMetrics will be recreated as described above using measured features of the device, and as long as the minimum number of categories are correct (three in this example: the tolerance value), they can be combined with the stored values to create the co-ordinates that can be interpolated to reproduce the function above and thus regenerate the ICMetric key.
  • the categories are combined to produce a key with a 256-bit key with theoretical entropy of up to 2 135 unique values.
  • the example given here gives specific examples for features that can be easily altered to create more complex categories with higher entropy.
  • Category 2 could use more characters of the Wi-Fi SSID
  • Category 3 could use a combination of contacts or use a variety of different filters based on other aspects of the contact details and/or Category 4 could be extended by making use of multiple images. All of these examples increase the complexity of each category respectively.
  • the RSA cryptographic system is a prime example of a typical system that could be integrated with ICMetrics.
  • an ICMetric key may be employed as the private key " d' " of the asymmetric key pair. This key is then hashed twice with SHA-256 before being used.
  • the private key must be physically stored on the device, if it is to decrypt data that has been encrypted with its public key. This leaves these systems vulnerable to backdoor attacks, as it is theoretically possible to gain access to and steal this private key.
  • ICMetric technology is used to generate the private key, then the private key would not need to be stored, but could be regenerated when required from the feature values.
  • n The modulus for both the private and public keys, named n, is then calculated using:
  • n p * q
  • the offset must be selected such that all three rules hold true.
  • the function in this example may use addition or the XOR bitwise operation in order to return an appropriate value for d, although many options are possible here.
  • the public key exponent e can then be derived by employing the extended Euclidian algorithm.
  • the values n and e are retained as the public key exponent as usual. Additionally, it is necessary to retain the function f and offset locally on the device.
  • An advantage of the system is that d can be generated on demand using rule 3 and therefore the values d', d, p, q and ⁇ ( ⁇ ) can all be discarded as soon as e has been generated. However in this system, the e value will not be conveniently small and therefore the encryption process will not be optimally fast.
  • ECC Elliptic Curve cryptography
  • the user-specific key generation stage produces a private and public key pair on a system user's device.
  • the private key dA is randomly selected with the constraint that it falls within multiplicative order of G, therefore it must be within the bounds [1 , n-1 ].
  • dA can be produced with relative ease through the ICMetric key generation process.
  • the ICMetric key must only adhere to the single rule in that it falls within the multiplicative order of G. If this rule is met the ICMetric key can be used as dA. If the ICMetric key does not adhere to this rule, the modulo-operation must be applied to dA using n as the modulus.
  • the ICMetric-generated dA can then be applied to the following trapdoor function in order to generate its public key QA counterpart:
  • the public key QA can now be distributed between each other user of the system and stored alongside the other parameters.
  • the distinct advantage of using ICMetric technology in the generation of dA is that it can now be discarded at this point in the process; there is no need to store it.
  • dA can once again be immediately generated through the use of ICMetrics.
  • the verification process can be undertaken as it traditionally is, as each device's QA must still be stored in memory.
  • Figure 4 shows two key generation processes; a routine execution and a fault analysis attack.
  • the bit values recorded from these environmental conditions are different during a routine execution compared to a fault analysis attack.
  • the obscure device features will remain the same and thus can usually be revealed during such an attack.
  • the differing environmental factors produced during an attack can be used to change the stable values that an attacker is attempting to collect. Any attempt to induce a fault in the system will in effect change any subsequent results that the system can produce therefore further obscuring the inner workings of that system.
  • the present techniques suitably permit augmentation of the security offered by traditional security systems by incorporating a technology to derive security identifiers or even encryption keys from the operating characteristics of the device utilised.
  • password-based security systems can be enhanced by incorporating a technology to derive security identifiers or encryption keys, called ICMetrics, from the operating characteristics (or features) of the device on which the password is entered by combining both password and ICMetrics to form an enhanced password as shown in Figure 5.
  • ICMetrics a technology to derive security identifiers or encryption keys
  • the concept of the password-enhancing technology is to increase the strength of the security offered by a password-based authentication system.
  • password-based systems suffer from low entropy (number of possible permutations) or are easy to guess (the user has to remember the password), or the password is written down.
  • ICMetrics is a technology where a large and complex unique identifier that cannot be feasibly committed to memory can be generated on demand rather than storing and reading device-specific data when needed.
  • a fundamental property of the ICMetric technology which allows it to operate is the metrics of characteristics of a system which, within the context of an ICMetric system, are termed features.
  • the password enhancer approach is designed to employ this ICMetric technology to derive a strong password without requiring the user to remember the complex derived password or having to store the password on the device where it can be stolen.
  • the password enhancing technology adds a second, ICMetric-based, factor (510, identified as "Device ICMetrics" in Figure 5) to a what-you-know password-based authentication system.
  • ICMetric-based, factor 510, identified as "Device ICMetrics” in Figure 5
  • the feature values provide a what-you-have factor in the authentication system.
  • the system combines the device ICMetric with the password 504 supplied by the user 502 to generate a single value (508, the "Enhanced Password” identified in Figure 5), which is passed on to the client service 506 as the actual password.
  • a single value (508, the "Enhanced Password” identified in Figure 5)
  • the combination can, for example, be performed by using a one-time pad and/or secret sharing, as discussed in more detail below.
  • the application can run as an extension in a browser at the device. It is possible to integrate the password enhancer via the change password service by navigating to the web page where a user can supply a new password for the server to store a hashed copy for future authentication. After supplying the current password, the password enhancer extension can be launched directly in the browser, and can have an input field to collect a user password that the user will need to remember, and a call to action to convert this basis password into a strong (enhanced) password.
  • the system can deal with a case where specific requirements, such as requirements in a set of requirements are placed on the required password by the server, such as a number of uppercase characters, a number of lowercase characters, a number of numeric digits, a number of symbolic characters, the length of the password, and any characters not to include (see Figure 6).
  • the set of requirements may comprise more than one requirement. It operates by allowing the user to generate a new (enhanced) password 606 (which can be generated in dependence on a user password 604) stipulating if the enhanced password 606 should address the requirements such as those discussed above.
  • a basis ICMetric value 602 can, for example, be created by using two images stored on the device 600 and selected as a symmetric encryption key for encrypting the hash of the second image selected. Characters are then derived from each pair of characters in the encrypted hashed value. Characters are suitably derived by taking the value modulo the valid range of ASCII character codes plus minimum valid ASCII character value to ensure the resulting password passed to the server represents a valid character. The character may then be filtered against the configuration and concatenated to the final password string.
  • both the "! and “@” would be mutated (for example at a Requirements Adaptation module 608) to valid characters.
  • the extension can populate the new password field in the web form with this new password.
  • the app can encrypt a string with the new hashed password which can be used to verify features offline when performing operations like changing a user's password.
  • the polynomial degree and total number of shares (i.e. the number of secret shares) to create is supplied to the application prior to the polynomial being generated.
  • the user's passwords and feature values are hashed and XOR'd with their associated point on the polynomial and the result of this logical operation is stored.
  • the user password, feature values, and any recovery phrase (which would form an additional polynomial point to circumvent the ICMetric should this be deemed a necessary requirement), can be changed on the device by simply XOR'ing the appropriate saved value with the existing value then XOR'ing the result with the new value. Significantly, this does not require any intervention by the server at any point in this process.
  • a polynomial to derive a password not only allows the system an acceptable level of robustness but it also allows the addition and removal of features, and other data that can be used as a substitute to features on a device, like the above-identified recovery phrase.
  • This can offer the guarantee that the system is always accessible even in the result of the ICMetric features failing due to errors in the configuration, but the trade-off is a loss of additional security.
  • This approach also boasts the advantage of being independent of the server.
  • a user can launch an extension on the login page of a website, where they can enter their easily memorable credentials into the extension's view before requesting the extension to invoke the app to XOR the submitted hashed values, and read feature hashed values with the saved values and calculate the Y-intercept.
  • the extension can then populate the password field on the web page with the result of the calculation before it is sent to the server for
  • the application is designed to provide additional security, directly in the default browser of a device such as a mobile device, for password-based authentication protocols.
  • a device such as a mobile device
  • FIG 7. An example is illustrated in figure 7.
  • browsers are shown on a mobile telephone (an iPhone, figure 7A) and a tablet computer (an iPad), both running iOS.
  • the browser used in the illustrated example is the Safari web browser. Entering the user's password without using it in conjunction with the device's features will result in authorisation failing for the user.
  • the app extension can be launched from the share button in the browser (figures 7B and 7C). Clicking on the appropriate icon launches the extension over the current web page (figures 7D and 7E).
  • the user's password is entered in this User Interface and the ICMetric process is initialised after the populate button is pressed.
  • the extension calls functions in the associated application to read feature values and calculate the Y-lntercept, the result of which is the password to send to the server. After the final password is calculated it is populated into the web field (figures 7F and 7G) so it can be sent to the server, for example over SSL/TLS, for hashing and verification.
  • Correlated features are desirable, as they provide a greater level of obfuscation than singular features. This is because they are derived from singular features.
  • a part of the obfuscation of the ICMetric key generation process is related to hiding the list of the features that are used in the process.
  • Singular features are features that are measured directly from the device rather than being derived.
  • Correlating features adds an extra step when trying to recreate the values, as the correlated values have to be generated and cannot be read directly from a device.
  • each correlated feature can itself be used as a feature, which has the benefit of increasing the entropy of the key, generated by the ICMetric algorithm.
  • a correlated feature that is chosen can be the subset of features that are more stable than the singular feature, as they represent a relationship between features rather than coming from a specific range, meaning that there is less intra-sample variance, thus increasing reproducibility of the generated key. While a basic analysis can focus on correlations between two features, this can be extended to look at any number of features together.
  • Table 6 shows example embedded hardware features used to produce a correlation analysis, such as a correlation matrix, of all the feature pair combinations.
  • Each point in the matrix represents the correlation between the feature relating to the row and the feature relating to the column where the identity of the feature may be read from Table 6.
  • the colour (or shading in a greyscale representation) of the square at that point is how strongly the features are correlated on a scale from yellow (lighter) to red (darker) where yellow represents a strong positive correlation, red represents a strong negative correlation and orange (in between lighter and darker extremes) represents no correlation.
  • Table 6 The entries in Table 6 are suitably defined as below. It will be understood that these are only example definitions, and that variations to these definitions will be readily apparent. Taking the first definition, of MemFree, as an example, whilst the definition provides that it is the amount of unused RAM in kilobytes, it might instead be some other division of memory, such as megabytes.
  • MemFree The amount of physical RAM, in kilobytes, left unused by the system.
  • Buffers The amount of physical RAM, in kilobytes, used for file buffers (storage for raw disk blocks).
  • Active Memory The total amount of buffer or page cache memory, in kilobytes, that is in active use (not reclaimed/swapped out).
  • Inactive Memory The total amount of buffer or page cache memory, in kilobytes, that is free and available.
  • Active_anon Anonymous memory that has been used more recently and usually not swapped out.
  • lnactive_anon Anonymous memory that has not been used recently and can be swapped out.
  • Active_file Pagecache memory that has been used more recently and usually not reclaimed until needed.
  • Mapped The total amount of memory, in kilobytes, which has been used to map devices, files, or libraries using the mmap command.
  • KernalStack The memory the kernel stack uses. This is not reclaimable.
  • PageTables The total amount of memory, in kilobytes, dedicated to the lowest page table level.
  • Committed AS The total amount of memory, in kilobytes, estimated to complete the workload. This value represents the worst-case scenario value, and also includes swap memory.
  • VmallocUsed The total amount of memory, in kilobytes, of used virtual address space.
  • VmallocChunk The largest contiguous memory block of available virtual address space.
  • the protection of existing private keys represents a significant use case for the technology discussed herein. This may be achieved by several mechanisms representing increasing level of protection in each case.
  • the derived ICMetric 902 is combined with a private key 904, using a suitable combination function 906 such as a one-time pad (XOR function) to generate an Enhanced key 908, which in some examples can also be combined with symmetric blockcyper algorithm such as AES.
  • a suitable combination function 906 such as a one-time pad (XOR function)
  • Enhanced key 908 which in some examples can also be combined with symmetric blockcyper algorithm such as AES.
  • AES symmetric blockcyper algorithm
  • ICMetric regeneration is required to release the Private Key.
  • a cipher block chaining approach can be utilised in some examples, such that at each key access iteration, a new enhanced key is generated from the previous enhanced key, thereby ensuring the stored value is unique at each iteration.
  • An initialisation vector (IV) is naturally required here, which may be a component of the ICMetric if sufficient entropy is available, but this need not be the case.
  • the combination suitably includes an additional encryption step, e.g. AES using the ICMetric as the "key", to prevent k(i+2) from being the same as k(i).
  • Key access may be achieved in the standard fashion of cipher block chaining, using the ICMetric key for the AES step k(i-1) as the one-time pad step, where k(0) is the initialisation vector (IV).
  • ICMetric key for the AES step k(i-1) as the one-time pad step, where k(0) is the initialisation vector (IV).
  • IV initialisation vector
  • the features of a device can be logically categorized into specific sets.
  • the device features contained within these sets share similar traits or are affected by the same modifications and reorientations of a device.
  • a practical implementation of ICMetric technology could potentially use hundreds of these feature sets. With such a large potential for scaling it cannot be assured that every feature within every set will produce the same result every time ICMetrics is used on a device. Fault tolerance must be created for these sets in order to create a system that not only produces a key that is highly unique but one that is also wholly reliable. This can be achieved for ICMetric technology through the use of a secret sharing cryptographic algorithm, the details of which are discussed below.
  • this algorithm can be applied in the same way within specific sets, allowing a single set to contribute to the key even if it contains a volatile feature that could sometimes potentially fail.
  • Specific weighting can also be applied to certain features and sets, defining how important it is for them to contribute to the key. Some features are much less volatile than others and thus changes in their values should be dealt with uncompromisingly. For example, the IP address may be allocated a higher weighting indicating its increased reliability for deriving the identity of the system whereas specific benchmark data may be less reliable.
  • This may also be applied to feature sets rather than individual features. For example, in the feature sets introduced below, feature category 3 (based on a contact list) could be allocated a lower weighting than feature category 2 (based on network connection and availability) indicating its lower reliability.
  • the feature sets produce specific length words (termed mini-ICMetrics) and after they have been generated and normalised during the calibration phase the secret sharing will be determined.
  • the tolerance of the system is set in order to declare how many of the mini-ICMetrics are required to rebuild the secret.
  • the mini-ICMetrics are the sets and the secret is the un-hashed ICMetric key.
  • the secret sharing is set up in a manner that allows for multiple levels of security.
  • the different levels of security provide distinct levels of access to the system, which we call the "tolerance" of the system.
  • the tolerance can be modified to allow partial access into the system only if the tolerance is set low enough to allow for multiple incorrect shares.
  • a polynomial is generated for each access level of security required in the system.
  • the degree of the polynomial is equal to the number of mini- ICMetrics required to gain access minus one. For example, if three shares were required then a quadratic polynomial would be generated.
  • Figure 11 shows an example of how the intercept may be generated for a 1 st degree polynomial (i.e. a polynomial of order one).
  • Each polynomial is evaluated using the category values as an argument to generate a set of values.
  • the resultant set of values comprise the Y values from the co-ordinate pairs where the X values are the category values.
  • Each set of Y values is suitably stored with the degree of the polynomial that was used to generate them.
  • the polynomials and the category values may be discarded. Thus only the Y values may be left on the system, which alone cannot be used to recreate the polynomial that generated them.
  • the features are measured from the device and the mini-ICMetrics regenerated.
  • Each polynomial has a set of Y values that are associated with it, saved on the system. To recreate each polynomial a subset of the Y values is used.
  • the size of the subset is equal to the minimum number of mini-ICMetrics required for that polynomial.
  • the Y values are recombined with their corresponding category values to create co-ordinates.
  • the co-ordinates are interpolated to generate a polynomial.
  • the generated polynomial's Y intercept is saved as one of the possible ICMetric keys. This process is repeated for all the subsets of co-ordinate pairs to obtain a set of ICMetric keys.
  • the set of keys is verified to verify if a correct key was generated using a subset of the correct categories.
  • the key is verified by attempting to decrypt a message that was previously encrypted with the ICMetric key.
  • the advantage of this process is that the ICMetric key is not stored on the system and the only values that are stored are one half of the co-ordinates that are necessary to generate the polynomial that produces the key.
  • the one half of the co-ordinates that are stored on the system cannot be used to find out the polynomial that was used to generate them. Additionally, a new ICMetric key can be generated any time the system needs to be changed or reset.
  • the system is also designed to protect against the execution of code that is not original code the system designer intends to execute. This is to ensure that the software running continuously on a device, such as an embedded loT device, has essentially the same behaviour as the original program for the purposes of security, and to detect any possible changes on the trusted software.
  • the basis of our proposed system of ICMetrics is akin to dynamic systems analysis, which analyses the execution of a program on an embedded architecture. Thus, the system presented is mainly for flagging rather than directly stopping execution of malicious code.
  • a common theme among many security attacks is hijacking the trusted code at run-time, so even if the original code is not malicious by intent, it can be manipulated by an attacker
  • the most common method would be the exploitation of a buffer overflow to overwrite a return address, altering program control flow to a malicious code.
  • the proposed system monitors the executing program continuously while constructing its behaviour to detect any changes. It is observed that any behavioural difference in the program execution trace can be detrimental and must be identified in real-time by monitoring the system behaviour.
  • the proposed intrusion detection method will not prevent buffer overflow, but it could detect the abnormal behaviour caused by buffer overflow by monitoring system behaviour.
  • features may be grouped together into related feature sets and a threshold for the number of valid feature groups needed to generate a password correctly may be set.
  • the strong password is suitably the Y-intercept
  • the feature groups are suitably points on the polynomial
  • the threshold is suitably the degree of the polynomial plus one.
  • two features that could change value between two locations could be the IP address of the device and the SSID of the network to which the device is connected.
  • the hashed values of the user's password and the device's features can both make up points on a polynomial, and this implementation of the two factors allows the derived password to be sent to the client service (representing any server and/or service to which communication or password / credential-based access is required) for authentication without it ever knowing that both a user's password and the user's device are required before a correct password can be generated.
  • this two-factor authentication is completely transparent to the client service which means it can be integrated into existing systems that already use password-based authentication very quickly and easily without requiring any modification to the server side, as the server is simply not involved.
  • the feature category 1 (illustrated in figure 12) may comprise network-related features (mobile country code, mobile network code and ISO country code, for example).
  • Feature category 2 may be formed by combining features such as Bluetooth services ON/OFF, WI-FI ON/OFF, and name of Wi-Fi for example (as illustrated in figure 13).
  • Information from the user's contact list may be utilized to generate feature category 3 (as illustrated in figure 14).
  • Feature category 4A and 4B may be formed based on information related to some specific images stored on a test device (as illustrated in Figure 15 and Figure 16).
  • the number of bits required for each feature included in these feature categories, along with the word length of each feature category, is suitably selected, for example according to system requirements/capabilities. As illustrated in figured 12 to 16, in this example the word length was fixed at 64 bits (8 bytes) for an individual feature category.
  • An embodiment to increase the robustness of the system suitably allows failed sets to "evolve" into new values when the overall number of successful sets is sufficient to allow the polynomial to be solved.
  • the mapping for the failed sets is adjusted so as to make the failed values lie within the range of valid values. In this way, on subsequent invocations of the system, the set will encompass the new values, potentially allowing a different feature set to fail.
  • a simple illustration would be where the number of contacts on a phone increases dramatically causing a feature set to fail. If other sets are still capable of generating a valid set and hence the polynomial is still solvable, then the mapping employed is adjusted so as to allow the new number of contacts to again produce a valid point on the polynomial. This can be done by adjusting the point coordinate generated by the new values.
  • Entropy smoothing (illustrated in Figure 17) represents an advantageous embodiment in which additional protection from attacks can be provided. It ensures that each of the generated keys is approximately equally likely to occur and thus neutralises the types of attacks which would focus on the most likely keys.
  • An accurate entropy smoothing algorithm is essential to ensure the security of the system. It depends fundamentally on the probability distributions of the features employed by the ICMetric system. Any error in the probability distributions will naturally give rise to probability "spikes" in the keyspace, where some keys are more likely to occur than others. It is thus desirable to minimise such spikes, as they naturally represent a means of attacking the system.
  • Spoofing and device cloning both concern an attack on the system that attempts to impersonate a trusted device by modifying an alternate device to produce the same ICMetric as the trusted device.
  • This is related to entropy smoothing, as poor entropy smoothing will allow the probability distributions of features to provide information as to potentially successful cloning scenarios.
  • Entropy smoothing is a process of combining candidate key values of relatively low probability such that the resultant combined key is equally likely to occur as those candidate key values that originally exhibited a high probability. The fundamental process is thus in determining the probabilities and combining them efficiently within the resulting space. To achieve this latter aim, the novel approach of calculating the probability distribution of the correlated features in two ways is taken.
  • the value of the correlation coefficient itself is employed as a feature, as identified above, thus replacing the feature values within the feature sets. This allows for the inclusion of features which may otherwise be excluded due to poor discriminatory factors and also in that their distributions are likely to show a better distribution.
  • features may be combined using a weight matrix specifically designed to improve the probability distribution of the resulting feature sets.
  • entropy smoothing is integrated concurrently within the construction of the normalisation maps associated within the feature sets and is unique to the present ICMetric approach.
  • peers may be introduced into a secure group by using a trusted peer to vouch for a new peer such that the new peer can then be a recognised part of the group, exchanging information between other peers in that group.
  • This system allows a secure group of trusted peers to grow without the problem of needing to use a certification authority to verify the identity of a previously unknown peer.
  • the peers will each represent a point on a polynomial for secret sharing, analogously to how it is employed above, where solving a polynomial results in a value that can be used as a key.
  • the points on a polynomial used for secret sharing were represented by feature sets, but for the present discussing in the context of secure groups, each point is represented by a device.
  • One example of how a group of trusted peers could be set-up is in an office environment, where all the work devices that will be authorised to communicate with each other are gathered together.
  • the polynomial will require any two devices to authenticate a device so the group consists of only two devices when initially setup. Both devices will represent a point on the polynomial of order one, where calculating the Y-intercept using the device's points will produce a key that can be used to decrypt data. This ensures no unknown device outside the trusted group can decrypt any encrypted data where the encryption key used is the Y-intercept for the polynomial.
  • a Y-intersect is generated for the polynomial via a suitable secure random process (if sufficient entropy is available from within the ICmetric, some of the ICmetric entropy may be employed here). Generating the Y-intersect first, before calculating the y-offsets would allow to the system to revoke potentially compromised peer polynomial points by generating a new intercept and new offsets. This allows the key to change whilst still keeping it relevant to a device's ICMetrics.
  • both devices can generate their own X value for an X, Y co-ordinate pair.
  • One way this can be done is to generate their ICMetric key and hash it twice.
  • N devices are needed to start with and an order n - 1 polynomial created a during the system setup.
  • n - 1 polynomial created a during the system setup.
  • Existing group members can introduce new peers by requesting a unique identifier from the peer to introduce. Once the group member receives this, it can place this value on to an existing polynomial already used for identifying trusted peers.
  • many military decisions require the authorisation from additional peers before they can be asserted. This responsibility can be shared between peers through the division of a single key into multiple parts. It should also be possible to freely introduce peers to this responsibility. When sufficient parts are reconstructed, the initial key can be validated. It is therefore appropriate that the security of these parts be guaranteed.
  • the following example shows how ICMetrics can be used to provide the parts of such a shared key securely.
  • a group of known peers are set up to communicate with each other over a shared secure channel 2.
  • a subset of the peers are required at all times for communication to occur
  • Each peer of the subset produces a portion of a shared key; each portion can be derived from each device's ICMetric process

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Theoretical Computer Science (AREA)
  • Computing Systems (AREA)
  • General Physics & Mathematics (AREA)
  • Algebra (AREA)
  • Physics & Mathematics (AREA)
  • Mathematical Analysis (AREA)
  • Mathematical Optimization (AREA)
  • Mathematical Physics (AREA)
  • Pure & Applied Mathematics (AREA)
  • Storage Device Security (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Collating Specific Patterns (AREA)

Abstract

L'invention concerne un procédé permettant de générer une clé de chiffrement destinée à être utilisée dans un processus de chiffrement sur un dispositif, ledit procédé consistant à : mesurer les valeurs respectives d'une pluralité de caractéristiques du dispositif afin de générer une pluralité de valeurs caractéristiques ; normaliser les valeurs caractéristiques à l'aide d'une carte de normalisation respective pour chaque caractéristique afin de générer une pluralité de valeurs normalisées ; et générer la clé de chiffrement en fonction des valeurs normalisées.
PCT/GB2018/050758 2017-03-24 2018-03-23 Justificatifs d'identité de sécurité WO2018172782A1 (fr)

Priority Applications (2)

Application Number Priority Date Filing Date Title
US16/497,311 US11133930B2 (en) 2017-03-24 2018-03-23 Security credentials
GB1913273.7A GB2574545A (en) 2017-03-24 2018-03-23 Security credentials

Applications Claiming Priority (8)

Application Number Priority Date Filing Date Title
GB1704746.5 2017-03-24
GB1704744.0 2017-03-24
GBGB1704746.5A GB201704746D0 (en) 2017-03-24 2017-03-24 Security credentials
GBGB1704744.0A GB201704744D0 (en) 2017-03-24 2017-03-24 Security credentials
GBGB1704743.2A GB201704743D0 (en) 2017-03-24 2017-03-24 Security credentials
GB1704742.4 2017-03-24
GBGB1704742.4A GB201704742D0 (en) 2017-03-24 2017-03-24 Security credentials
GB1704743.2 2017-03-24

Publications (1)

Publication Number Publication Date
WO2018172782A1 true WO2018172782A1 (fr) 2018-09-27

Family

ID=61868540

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/GB2018/050758 WO2018172782A1 (fr) 2017-03-24 2018-03-23 Justificatifs d'identité de sécurité

Country Status (3)

Country Link
US (1) US11133930B2 (fr)
GB (1) GB2574545A (fr)
WO (1) WO2018172782A1 (fr)

Families Citing this family (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11411718B2 (en) * 2020-06-12 2022-08-09 The Boeing Company Partial overlapping multi-key encryption of a data set
EP4002792B1 (fr) * 2020-11-13 2024-10-16 Secure Thingz Limited Appareil et procédé de fourniture de dispositifs électroniques
BR102021001278A2 (pt) * 2021-01-22 2022-08-09 Rogerio Atem De Carvalho Dispositivo e método para autenticação de hardware e/ou software embarcado
JP2022148408A (ja) * 2021-03-24 2022-10-06 キヤノン株式会社 通信装置、通信方法、およびプログラム
US12047502B2 (en) * 2021-05-05 2024-07-23 Verizon Patent And Licensing Inc. Systems and methods for backing up a hardware key
US11922191B1 (en) * 2021-06-01 2024-03-05 Amazon Technologies, Inc. Identification of missing content features in rendered user interfaces
CN119150364B (zh) * 2024-11-18 2025-04-04 南通千鸟纸通宝信息科技有限公司 基于区块链的交易数据智能化保护方法及系统

Family Cites Families (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7181017B1 (en) * 2001-03-23 2007-02-20 David Felsher System and method for secure three-party communications
US9438417B2 (en) * 2014-08-12 2016-09-06 Robert Bosch Gmbh System and method for shared key agreement over untrusted communication channels
GB201511793D0 (en) * 2015-07-06 2015-08-19 Pipa Solutions Ltd Biometric security for cryptographic system
JP6882666B2 (ja) * 2017-03-07 2021-06-02 富士通株式会社 鍵生成装置および鍵生成方法
US10749694B2 (en) * 2018-05-01 2020-08-18 Analog Devices, Inc. Device authentication based on analog characteristics without error correction
US11270005B2 (en) * 2019-06-04 2022-03-08 Schneider Electric USA, Inc. Device data protection based on network topology

Non-Patent Citations (3)

* Cited by examiner, † Cited by third party
Title
HOPKINS A B T ET AL: "Ensuring data integrity via ICmetrics based security infrastructure", ADAPTIVE HARDWARE AND SYSTEMS, 2007. AHS 2007. SECOND NASA/ESA CONFERENCE ON, IEEE, PISCATAWAY, NJ, USA, 5 August 2007 (2007-08-05), pages 75 - 81, XP031464147, ISBN: 978-0-7695-2866-3 *
R. TAHIR ET AL: "A Scheme for the Generation of Strong ICMetrics Based Session Key Pairs for Secure Embedded System Applications", 2013 27TH INTERNATIONAL CONFERENCE ON ADVANCED INFORMATION NETWORKING AND APPLICATIONS WORKSHOPS, 1 March 2013 (2013-03-01), pages 689 - 696, XP055483227, ISBN: 978-0-7695-4952-1, DOI: 10.1109/WAINA.2013.143 *
YEVGENIYA KOVALCHUK ET AL: "Overview of ICmetrics Technology - Security Infrastructure for Autonomous and Intelligent Healthcare System", INTERNATIONAL JOURNAL OF U- AND E- SERVICE, SCIENCE AND TECHNOLOGY, 30 September 2011 (2011-09-30), pages 49 - 60, XP055483303, Retrieved from the Internet <URL:https://www.researchgate.net/profile/Gareth_Howells/publication/266296056_Overview_of_ICmetrics_Technology_-_Security_Infrastructure_for_Autonomous_and_Intelligent_Healthcare_System/links/54b3bbd10cf26833efceb286/Overview-of-ICmetrics-Technology-Security-Infrastructure-for-Autonomous-and-Intelligent> [retrieved on 20180611] *

Also Published As

Publication number Publication date
US11133930B2 (en) 2021-09-28
GB2574545A (en) 2019-12-11
GB201913273D0 (en) 2019-10-30
US20200382295A1 (en) 2020-12-03

Similar Documents

Publication Publication Date Title
US11133930B2 (en) Security credentials
CN109756338B (zh) 认证装置、验证装置的计算机实现方法和计算机可读介质
CN109643359B (zh) 控制密钥-值存储的验证
US11531758B2 (en) Provision of domains in secure enclave to support multiple users
US10484365B2 (en) Space-time separated and jointly evolving relationship-based network access and data protection system
JP6489328B2 (ja) 動的なマニューシャの予想される変化に基づく暗号セキュリティ機能
CN113691502B (zh) 通信方法、装置、网关服务器、客户端及存储介质
US11455432B1 (en) Multi-user storage volume encryption via secure processor
US20160006570A1 (en) Generating a key derived from a cryptographic key using a physically unclonable function
JP5857726B2 (ja) 温度センサ、暗号化装置、暗号化方法、及び個体別情報生成装置
US20160197729A1 (en) Location aware cryptography
US11101989B2 (en) Trusted ring
US20220167152A1 (en) Systems and methods for authenticating a subscriber identity module swap
Shantha et al. Security analysis of hybrid one time password generation algorithm for IoT data
TW202420776A (zh) 客戶端－伺服器系統、非暫時性電腦可讀取儲存媒體、安全地操控密碼散列之方法以及確保於客戶端中恢復使用者提供密碼僅經由認證伺服器之方法
US20200117795A1 (en) System and method for generating and authenticating a trusted polymorphic and distributed unique hardware identifier
US8954728B1 (en) Generation of exfiltration-resilient cryptographic keys
Wee et al. Excavating Vulnerabilities Lurking in Multi-Factor Authentication Protocols: A Systematic Security Analysis
CN118153075B (zh) 一种数据存储加密方法、装置及电子设备
CN116049802B (zh) 应用单点登陆方法、系统、计算机设备和存储介质
EP3836478A1 (fr) Procede et systeme pour cryptage des donnees en utilisent des clés cryptographiques
Hu et al. Assuring spatio-temporal integrity on mobile devices with minimum location disclosure
CN111083156B (zh) 认证方法、装置、电子设备和存储介质
Islam et al. Detecting Compromise of Passkey Storage on the Cloud
CN111046440A (zh) 一种安全区域内容的篡改验证方法及系统

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 18715086

Country of ref document: EP

Kind code of ref document: A1

ENP Entry into the national phase

Ref document number: 201913273

Country of ref document: GB

Kind code of ref document: A

Free format text: PCT FILING DATE = 20180323

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 18715086

Country of ref document: EP

Kind code of ref document: A1

点击 这是indexloc提供的php浏览器服务，不要输入任何密码和下载