Tamper-proof data encoding for mobile devices

Abstract

Systems, methods, and devices can protect secrets on devices with limited memory while still providing tamper resistance. To achieve lower memory usage, embodiments can apply a memory dependency function MHF to a secret S to obtain a result Y, which can be used in an encoding process to obtain a code C. After applying the MHF, a proof function can generate a proof value used in a decoding (e.g., a computational verification process) of the code C. The code C can include the proof value, the secret S, and the result Y, and can be sent to a decoding device that verifies the code C as part of a decoding process.

Description

Background Art

[0001] When secret data (e.g., a secret key used for encryption) is stored in a "secure" memory of a device, an attacker can still tamper with the "secure" memory using a fault attack. In a fault attack, the values ​​in a memory cell are changed, and the output of a security function (e.g., in a secure element that includes the secure memory) can be used to derive the original secret data. Once the attacker knows the secret data, she can use it to compromise the security of the associated system, such as by decrypting a ciphertext encrypted with the secret key, which is part of the recovered secret data. As another example, an attacker can use secret data in an authentication protocol to improperly access resources. Such an attack may occur when a phone is stolen or malware is introduced.

[0002] The overall effectiveness of fault attacks as a method of hardware tampering and memory leakage makes fault attacks a widely used technique for accessing private data stored on consumer devices. For example, fault attacks may be effective against RSA or elliptic curve Diffie-Helman techniques, which can be used for transport layer security (TLS). As such, an increasing number of researchers are trying to find decoding schemes to protect data from memory vulnerabilities against fault attacks and similar forms of hardware tampering.

[0003] This attack can be partially addressed by using non-malleable code, so that secret data is stored by encoding it with non-malleable code. This encoding does not require a key and is therefore different from encryption. Using non-malleable code can allow the security element to detect whether tampering has been done, or produce the same output. However, non-malleable code requires the use of a decoding function in the security element. The attacker malware may include a decoding function or gain access to a decoding function and include an encoding function. This malware can use tampering to recover secret data. Existing protection technologies fail to address this malware and therefore leave open vulnerabilities.

[0004] The embodiments described herein address these and other problems individually and collectively. Summary of the invention

[0005] Embodiments of the present invention include systems, methods, and devices for protecting secrets on devices with limited memory while still providing tamper resistance. In order to achieve lower memory usage, embodiments may apply a memory-hard function MHF to a secret S to obtain a result Y, which may be used as part of an encoding process to obtain a code C. The encoding may be performed by a provisioning computer. After applying the MHF, a proof function may generate a proof value used in the decoding (e.g., a computational verification process) of the code C. The code C may include a proof value, a secret S, and a result Y, and may be sent to a decoding device verifying the code C as part of the decoding process, for example, when the secret S is required in a cryptographic function. The separation of the MHF from the proof function may allow decoding to use less memory while still ensuring that the encoding process requires sufficient memory.

[0006] According to one embodiment, a method encodes a secret on an encoding computer. One or more public parameters may be retrieved, wherein the one or more public parameters may be generated based on a memory-dependent function MHF and a security parameter λ. The memory-dependent function MHF may be applied to a secret S or a function (e.g., a hash) applied to the secret S to obtain a result Y. Applying the memory-dependent function MHF to the secret S may require at least N bytes of memory on the encoding computer, where N is at least one gigabyte. A proof function may use the secret S, the result Y, and one or more public parameters to determine a proof value π. A codeword C may be assembled based on the proof value π, the secret S, and the result Y. The codeword C may be sent to a device configured to store the codeword C and later decode the codeword C. The proof value π may be configured to be used by a decoding function of the device to verify the correctness of the result Y obtained from the memory-dependent function MHF using the secret S. The decoding function is operable to use k bytes of memory, where k is less than N, for example, 100 times smaller.

[0007] These and other embodiments of the present invention are described in more detail below.For example, other embodiments relate to systems, devices, and computer-readable media associated with the methods described herein.

[0008] Additional details regarding embodiments of the invention can be found in the detailed description and drawings described herein. BRIEF DESCRIPTION OF THE DRAWINGS

[0009] Figure 1 A mobile device is shown storing a secret sk in a secure element.

[0010] Figure 2 A tampered secure element is shown that may be located inside a mobile device.

[0011] Figure 3AThe correctness of the non-malleable code is shown. Figure 3B The non-malleability of non-malleable code is shown.

[0012] Figure 4 The use of a non-malleable code for protecting a secret stored in a secure element of a mobile device 400 is shown according to an embodiment of the present invention.

[0013] Figure 5 The benefits of using non-malleable code when storing secrets in a secure element to perform cryptographic functions in accordance with an embodiment of the present invention are shown.

[0014] Figure 6 An example of a fault attack on an encoded secret when a tampering attacker is able to encode and decode simultaneously is shown.

[0015] Figure 7 An example of an attacker being unable to successfully perform an attack on an encoded secret stored in a device due to limited memory resources on the device is shown in accordance with an embodiment of the present invention.

[0016] Figure 8 is a flow chart illustrating a method for encoding a secret according to an embodiment of the present invention.

[0017] Fig. 9 An example encoding / decoding scheme using a hash function according to an embodiment of the present invention is shown.

[0018] Fig.10 An example encoding / decoding scheme 1000 using publicly verifiable computations is shown in accordance with an embodiment of the present invention.

[0019] Fig.11 Shown from Fig.10 A depiction of the encoding / decoding scheme.

[0020] Fig.12 A block diagram of a provisioning apparatus according to an embodiment is shown.

[0021] Fig.13 A method 1300 illustrating a decoding process using codewords for use in a cryptographic function is shown in accordance with an embodiment of the present invention.

[0022] Fig.14 A block diagram of a mobile device according to an embodiment is shown.

[0023] Fig.15 A block diagram of an example computer system that may be used with systems and methods according to embodiments of the invention is shown.

[0024] the term

[0025] "Non-malleable code" may refer to a coding scheme in which decoding a codeword that has been altered (eg, by a tampering adversary) produces either the original (unaltered) message or a completely unrelated value that cannot be used to infer knowledge.

[0026] "Space-bound," "memory-bound," or "memory-dependent function" (MHF) may describe a function or task where the time required to complete the task is primarily determined by the amount of available memory required. For example, for a space-bound computational problem, the efficiency of a particular computational process may be most affected by the rate at which data can be read and stored in memory (i.e., memory bandwidth) rather than by the clock speed of the processor. Memory-dependent functions require a certain number of memory bits to execute. A strictly memory-dependent hash function is an example of a memory-dependent function. A memory-dependent function requires time T and space S to perform a normal computation, but if the amount of available space is less than S, then the amount of time increases significantly.

[0027] "Verifiable computation" can refer to programs that efficiently check the correctness of computations without performing the computations themselves. The goal can be to develop verification programs that are much more resource (space / time) efficient than the target computations themselves. For example, consider memory-intensive computations on a huge database via a cloud server. The client wants the server to perform some computation (e.g., aggregation) on the database, and verifiable computation can be used to check that the result is correct without actually performing operations on the data.

[0028] A "proof function" may refer to a function that produces a "proof value" that can be used to verify a computation. The proof value may be compact because it may be computed using relatively low memory (space), allowing the decode to be generated in low space. Using MHF during encoding may ensure that high memory is required, even when the proof function itself may be executed in low memory.

[0029] A "verification function" may refer to a procedure that uses a proof value to confirm that a code C was generated from a secret S by a specified encoding function.

[0030] "Security parameters" may refer to basic system parameters specified according to the required security level. All other metrics of the solution (eg, running time, required memory, etc.) may be measured according to the security parameters.

[0031] A "randomized algorithm" may refer to a computation that uses random bits drawn from a trusted source of randomness. On a particular input, the output of such an algorithm may follow a probability distribution.

[0032] A "deterministic algorithm" may refer to a computation that does not use any randomness, and on a particular input, the output of such an algorithm is fixed in that the output is determined solely by the input.

[0033] A "secure element" can be a tamper-resistant platform (e.g., a single-chip secure microcontroller) that is capable of securely hosting applications and their confidential and cryptographic data (e.g., key management) according to rules and security requirements set forth by a well-identified set of trusted authorities. Example form factors include Universal Integrated Circuit Cards (UICCs), embedded SEs, and microSDs. DETAILED DESCRIPTION

[0034] Embodiments describe the use of memory-dependent functions and verifiable computations to implement non-malleable codes, for example, allowing error detection or always providing the same input data when a non-malleable code is detected. Additionally, decoding can actually be implemented when encoding cannot be implemented with today's mobile devices, thereby preventing the mobile device from generating codes that can be used to improperly authenticate the device.

[0035] To implement such a non-extensible code, a server may encode a message (m), such as a secret key (sk), to generate a code (y) (also referred to as 'c'), and generate a proof value π corresponding to a specific m / y pair (also referred to as sk / c or m / c pair). The size of the proof value π may be constant regardless of the size of the message. Both the code and the proof value are then sent to the mobile device. In order to decode the message, the mobile device may need to verify the proof value. For example, the decoding function may need to be verified before the decoding functionality can be accessed. As another example, for example, when the code includes a message, verification may provide decoding. Therefore, a correct evaluation of the proof value may initiate a decoding operation, thereby allowing the device to decode the code and thereby obtain the message in plain text. The message can then be used in a function, such as by an encryption function to encrypt input data, wherein the encrypted output can be sent to another device.

[0036] In an embodiment, generating a proof value for new input data may consume significantly more memory than verifying a proof value for an existing message (m) / code (y) pair. Thus, given the limited amount of memory storage available on a mobile device, if an attacker were to introduce a fault into a stored code or during a decoding operation, the added fault cannot be integrated into the re-encoding operation due to lack of memory resources. Thus, the re-encoding operation does not leak any original information, and the attacker will not be able to deduce the encoding function, e.g., the relationship between the input and output codes of the encoding.

[0037] As part of requiring the encoding to use a large amount of memory, a memory-dependent function (MHF) can operate on a secret S or some other function of S. For example, the MHF can operate on the hash of S. This procedure ensures that for a given S, the MHF cannot be calculated in low space (memory). Since the MHF provides high memory requirements, less memory can be used for verifiable computational aspects. For example, a small amount of memory can be used to generate proofs and verifications so that the proofs and verifications can be performed on a mobile device. The proof function that generates the proof and the MHF can include an encoding function. The verification function can perform decoding. Therefore, a low-space adversary can only cover with a pre-computed encoding of S' that is clearly unrelated to S.

[0038] I. Tampering with the secure element

[0039] A mobile device pre-configured with a secret sk may be used for a variety of reasons. For example, the secret sk may be used as a secret key to encrypt communications. As another example, the secret sk may be used for authentication purposes so that the mobile device may obtain entry to a resource (e.g., a building, computer, or account). Depending on the requirements, the mobile device may use the secret sk to operate on input data (e.g., a challenge) to generate an authentication response when making a request to an authentication computer.

[0040] A. Encryption using secure elements

[0041] Figure 1 The mobile device 100 is shown storing a secret (sk) 115 in a secure element 110. The secure element 110 may store the secret 115 in a secure memory of the secure element 110. The secure element 110 may also include circuitry to execute a function 112, which is identified as F sk (·). Function 112 may operate on input 105 to provide output 120. Mobile device 100 may then send output 120 to recipient device 150, which may decrypt output 120 to obtain input 105.

[0042] This operation may be performed when the input 105 is to be encrypted using the secret 115 as an encryption key and sent as the output 120. The recipient device 150 may have been previously provisioned with the same secret, possibly having initially provided the secret to the mobile device 100. As another example, the recipient device 150 may provide the input 105 as a challenge to the mobile device 100. The recipient device 150 may then compare the output 120 to an expected result in order to authenticate the mobile device 100.

[0043] B. Tampering is used to determine the secret key

[0044] Unfortunately, an attacker may, for example, use a tampering function as a fault attack to compromise the security element. Thus, the attacker may be a tampering function installed on the mobile device. The tampering function may further penetrate the security element such that the secret data is manipulated, thereby generating output data that may reveal the content of the secret data. Thus, in this case, the repeated output of the security element after the tampering may be analyzed to reveal the secret data.

[0045] Figure 2 A tampered security element that may be located inside a mobile device is shown. Security element 210 may perform function 212 using secret 215. As shown, secret 215 has been tampered with, shown as sk' generated from the original secret sk. Tampered function A may be defined by sk':=A(sk). As an example, tampered function A may result from malware infecting security element 210 or physical tampering that may be performed using a laser on physical memory.

[0046] For example, an attacker can introduce faults into a memory (e.g., flash memory or dynamic random access memory (DRAM)) by selectively changing the charge state of the memory's capacitors (e.g., using a laser), and thereby performing a "bit flip" that causes a targeted row of bits in a memory cell to leak between a read operation and a write operation (i.e., a Rowhammer attack). These types of attacks are particularly prevalent in smaller devices that have memory cells designed for minimal power consumption, such as smartphones, tablet computers, and other mobile personal devices.

[0047] In this example, output 220 is generated from input 205 using function 212 and a stored secret, which is tampered secret 215 (shown as sk'). Since output 220 depends on the value of the stored secret, modifying the stored secret affects output 220. Therefore, information about the original secret sk is leaked through output 220. After multiple rounds of tampering, for different inputs and outputs, sufficient data sets indicate that an attacker can reconstruct the original secret sk from the inputs and outputs. It is advantageous to prevent such attacks.

[0048] The goal of the attacker is to recover the secret. If the mobile device is stolen, then someone can use it, but someone cannot recover the secret key because it is stored in the secure element. However, once they have tampered with the device and then try to use it, they will get a different response from the device.

[0049] Tampering can be performed by physical means, such as using a laser to change the secret. This tampering causes the memory to actually store a different value, and therefore operate in a slightly different way. The slight change in the response can be compared to the original response and used to make conclusions about the secret. This can be different if you cause some change in the device when it emits a password or sends out another type of data message, in a way that allows one to detect what the secret is. For example, if the first bit of the secret is a zero, then it will respond differently than if the first bit of the secret was a one.

[0050] In one specific case, a mobile device may store a mobile payment application, and subsequently store a secret somewhere in the application. An attacker may then rely on non-physical tampering means, such as by introducing malware into the application, to tamper with the secret stored in the application. For example, malware may blindly change a value sent to a trusted execution environment or hardware module.

[0051] II. Non-Extensible Code and Its Applications

[0052] Non-malleable codes can achieve a certain degree of resistance to tampering attacks. For example, a secret message m can be encoded to provide a stored code c. Even if the code has been tampered with, the decoding function can still provide the secret message m. Alternatively, the decoding function can provide an error indicating that tampering has been performed. If neither of these occurs, the decoded message can be a message that has nothing to do with the originally encoded message.

[0053] Figure 3A The correctness of the non-malleable code is shown. The secret message m is encoded by the encoding function 310 to obtain the code c. The decoding function 320 decodes the code c to obtain the original secret message m in the absence of tampering.

[0054] Figure 3B The non-extensibility of the non-extensible code is shown. Similarly, the security message m is encoded by the encoding function 310 to obtain the code c. But this time, the attacker 315 changes the code c to the code c'. Therefore, the decoding function 320 decodes the code c' to obtain m'. The decoding process can cause both code c and code c' to decode to m, and therefore m' is equal to m. However, if m and m' are different, then the decoding function 320 returns an error. In theory, the decoding function 320 can also include a verification function that can detect when m is not equal to m', that is, detection. The value ⊥ indicates an error. However, it is not clear how to determine such a verification function, especially when the decoding function 320 needs to be executed on a mobile device. Error detection does not need to be completely accurate, as long as m' is independent of m and therefore information cannot be obtained from the output generated using m'.

[0055] Thus, for a non-malleable code, the encoded message will either completely change when altered or will not change at all, or the error will be detected. Examples of error detection codes using computational verification are Algebraic Arithmetic Detection (AMD) codes (www.iacr.org / archive / eurocrypt2008 / 49650468 / 49650468.pdf) or tamper detection codes.

[0056] A. Protection of Secret Keys

[0057] Now, a method for storing a secret on a mobile device (e.g., Figure 1 Implementation of non-extensible code for the above situation.

[0058] Figure 4 The use of a non-extensible code for protecting a secret stored in a secure element of a mobile device 400 according to an embodiment of the present invention is shown. A secret (sk) 415 may be encoded by an encoding function 403 to obtain a code c. The encoding function 403 may be implemented by a provisioning device external to the mobile device 400. Examples of provisioning devices include a server provisioned via a network or a local device, such as by a direct wired or wireless connection (e.g., Bluetooth or Wifi). In various embodiments, provisioning may be performed by a manufacturer, a service provider (e.g., a cellular carrier), or a technician after a user has acquired the mobile device.

[0059] Code c may be provided to mobile device 400 and stored in secure element 410. Secure element 410 may include circuitry (eg, hardwired or programmable circuitry) for performing function 412 (eg, encryption) and for performing decoding function 407.

[0060] As part of executing an application (e.g., authentication or encrypted communication), a processor (not shown) of mobile device 400 may provide input 405 to secure element 410 to obtain output 420, e.g., for transmission to an external device. To generate output 420, decode function 47 retrieves code 417 from secure memory and decodes code 417 to obtain original secret 415. Function 412 operates on input 405 using secret 415 to obtain output 420.

[0061] B. Anti-tampering

[0062] Tampering categories cover tampering functions / algorithms that the device can tolerate without exposing the underlying data. Typically, encoding / decoding functions cannot tolerate all categories of tampering algorithms. Embodiments are directed to handling situations where it is difficult to tolerate tampering algorithms, for example, when the device is compromised.

[0063] A popular category of tampering is granular tampering. A secret can be encoded to obtain a codeword with two parts, c1 and c2. The two parts can be stored on the same device or on two physically separate devices. The attack must be performed independently on the two different parts of the codeword, where the two different decoding functions cannot see each other. The attacker knows that there are two parts, but the tampering algorithm cannot be related to each other because they are separated. The attacker may operate on one part, but actually needs to operate on both parts to expose the information.

[0064] Another category is global tampering, which means the attacker has access to the entire codeword. This category of tampering assumes that the attacker cannot decode or encode. In this case, the attacker can only slightly change the codeword and hope to decrypt the original secret, which is very difficult. No instances are provided where the attacker cannot decode or encode.

[0065] Figure 5 The benefits of using non-malleable code when storing secrets in a secure element to perform cryptographic functions in accordance with an embodiment of the present invention are shown. Figure 5 Shown side by side are Figure 2 and Figure 4 Example implementation scheme of .

[0066] Secure element 510 stores a secret sk to perform a function on input 505 to obtain output 520. Secure element 510 is vulnerable to tampering attacks, as described above.

[0067] The secure element 550 stores the code c generated from the secret sk using the encoding function. The secure element 550 decodes the code c to obtain the secret sk, which is then used to perform a function on the input 555 to obtain the output 570.

[0068] As shown, code c has been tampered with to obtain c'. Therefore, the decoding function is shown to output sk'. Assuming that the attacker can only modify code c, the value of sk' should provide three possibilities for the output.

[0069] For possibility 1, sk'=sk, for example, since the change between c and c' is small, the decoding function outputs the same value. For example, the decoding function can map more than one input to the same output. This procedure can be similar to an "error correction" mechanism, one of the implementation methods is to add redundancy to the codeword.

[0070] For possibility 2, the decoding function may detect that the decoded value does not correspond to the code c' and thus detect tampering. If tampering is detected, the decoding function may output a predetermined error character ⊥. How to determine this inconsistency between the code c' and the decoded value is described later.

[0071] For possibility 3, the decoding function determines that c' and the decoded value are consistent with each other, but this result should only be possible if sk is independent of sk' and sk' does not reveal any meaningful information about sk. This may happen when an attacker overwrites the encoding of sk with an encoding of known sk'; in this case, sk' is obviously independent of sk because the attacker already knows sk'. For non-malleable codes, if a single bit is changed when using the encoding algorithm, the response is completely independent of the original message, and therefore, the introduced fault cannot be used to derive the secret. "Independence" covers error detection and correct decoding that exploits the irrelevant sk'. Due to the non-malleable property of the code, the attacker will not be able to isolate the changes associated with a single bit reversal. In the event that a malicious program is introduced into an application, even if the malicious program were to overwrite the secret stored in the application with its own secret, no information about the original secret could be inferred.

[0072] For example, if an attacker can perform encoding and decoding, then the security element 550 is still vulnerable to tampering attacks. Specific encoding and decoding techniques may be public, such as part of a standard. Therefore, an attacker may generate malware that performs these functions. This attack is addressed in the next section.

[0073] III. More complex attacks

[0074] Unlike encryption using additional secret information (e.g., keys), such additional secret information is not used for encoding / decoding. There is no private key, mapping, or other authentication key for these encoding or decoding procedures. In addition, the encoding / decoding functions are generally known to the public, for example, as part of a standard. Therefore, there are coded secrets stored in the memory of the device, where anyone can decode, tamper with, and re-encode the secrets on the device. The device shown in the figure cannot prevent these operations.

[0075] Figure 6 An example of a fault attack on an encoded secret when a tampering attacker is able to encode and decode simultaneously is shown. Figure 6 Some actions performed in the embodiment of the present invention may be performed in a secure element of a mobile device or other base device, such as a fixed device. For ease of illustration, the secure element and the mobile device are not shown.

[0076] The secret (sk) 610 is encoded by an encoding function 620 to provide a code (c) 630. As described herein, this initial encoding may be performed by a provisioning device. Provisioning of the mobile device may cause the code 630 to be stored in a secure memory of a secure element. Provisioning may include installing a decoding function 660 so that the mobile device may use the secret 610, for example, to encrypt a message or perform an authentication procedure.

[0077] Once code c is stored, attacker module 640 can execute attack 600. Attacker module 640 may be malware installed on the mobile device through a network (e.g., when a user unknowingly selects a link that installs malware). As another example, someone may steal the mobile device and install attacker module 640.

[0078] In attack 600, attacker module 640 may retrieve or intercept code 630 from secure storage and perform the three listed actions (1)-(3). The interception of code 630 may occur when decoding function 660 attempts to retrieve code 630 and decode the code. In action (1), attacker module 640 may decode code (c) 630 to obtain secret (sk) 610. Decoding may be performed using only code of attacker module 640, or decoding function 660 may also be used. In action (2), attacker module 640 changes the secret by adding a secret thereto, thereby obtaining a changed secret sk':=sk+1. In this way, sk' is related to sk, and because of this relationship, knowledge of sk' fully reveals knowledge of sk. In action (3), attacker module 640 encodes the changed secret sk' using encoding function 620 to obtain changed code (c') 650. Since the original encoding was performed by the provisioning device, attacker module 640 will include encoding function 620.

[0079] After performing the attack 600, a decoding function 660 may receive the altered code 650 and decode the altered code to obtain an altered secret (sk') 670. The altered secret 670 may then be used in a function (e.g., encryption) applied to an input to obtain an output that depends on the altered secret 670, such as Figure 4 Therefore, any external person or software (i.e., outside the secure element) performing the attack can only see F sk′ (input). However, because sk is related to sk', an external entity can deduce sk. The attacker knows A (e.g., which specific bits or bit rows are inverted) and can therefore infer the secret 610 by systematically making changes and looking at the output of the security element, such as by providing the same input and determining how the output changes for different changes to the secret 610. As shown, this attack cannot be prevented without imposing further restrictions.

[0080] IV. Space-constrained tampering model

[0081] As mentioned above, a hacker can tamper with the "secure" memory of the device. The encoded value in the memory cell can be decoded, changed, and re-encoded to derive the original value. One solution to this type of attack is that the hacker is limited in time by the resources required for the encoding. The complexity in this case can be the number of bits required for the algorithm to run (i.e. the maximum memory required at any point in the algorithm). Therefore, the limit is the amount of memory available to execute the encoding function. Therefore, the encoding algorithm requires more memory than the attacker allows.

[0082] Ideally, tampering is resisted by using an encoding procedure that requires a large space (a large amount of memory) and a decoding process that can be performed in a small space (a relatively small amount of memory). With such a restricted encoding function, the attacker will not be able to re-encode the changed secret. If the attacker cannot re-encode, then the attacker cannot provide the changed code to the decoding function. The encoded value has a certain format, and the attacker may have a certain function for decoding the message, but the attacker cannot formulate an encoding that conforms to the format, such as a verifiable format. Therefore, no output is obtained from the secure memory. However, the inability to encode does not prevent the attacker from arbitrarily tampering with the state of the encoding to be permitted by the allowed memory. Non-extensible code should ensure that such tampering will cause one of the three situations mentioned above, thereby protecting the secret.

[0083] Figure 6 The need for re-encoding can be indicated. sk′ The operation of (input) is set to be performed using only the output of the decoding function 660. Therefore, the output value (e.g., output = F sk′ (input)) is to first provide the code to the decoding function 660. Therefore, the attacker cannot use sk' at action (2) to sk′ (input). In addition, an attacker may decode C to obtain SK, but the attacker cannot re-encode SK. Therefore, the attacker cannot change SK to SK' and then re-encode it to obtain C'.

[0084] The non-scalability requirement may make the task of allowing decoding and not allowing encoding even more difficult. Specifically, the decoding function may also require excessive memory and may be inefficient given the memory and processing power of current mobile devices. One solution (https: / / eprint.iacr.org / 2017 / 530.pdf) requires approximately 30-100MB of available computing space to verify each 128-bit message (e.g., as part of the decoding procedure), which is not very space efficient. Furthermore, these requirements increase with the message length (or security parameter) as a power of 4.

[0085] If the amount of memory required for decoding is so large that the mobile device cannot actually use the encoding / decoding scheme, then the solution is not feasible, even if the mobile device can be pre-provisioned with the code. For example, assume that the provisioning device (e.g., a provisioning server) has several terabytes of space for encoding, and can therefore encode the secret to obtain the codeword and provision the mobile device. This requirement for several terabytes of memory ensures that the mobile device cannot perform encoding, but if the mobile device does not have enough memory to perform decoding, then this limitation is not beneficial. Ideally, decoding should use several kilobytes of memory for practical use.

[0086] Figure 7 An example of an attacker being unable to successfully perform an attack on an encoded secret stored in a device due to limited memory resources on the device is shown in accordance with an embodiment of the present invention. Figure 7 Some actions performed in the can be performed in a secure element of a mobile device or other base device, such as a fixed device, which may have limited memory. For ease of illustration, the secure element and the mobile device are not shown. Figure 7 yes Figure 6 , but encoding is not possible.

[0087] The secret (sk) 710 is encoded by the encoding function 720 to provide the code (c) 730. Provisioning of the mobile device may cause the code 730 to be stored in the secure memory of the secure element. Provisioning may include installing the decoding function 760 so that the mobile device can use the secret 710 to, for example, encrypt a message or perform an authentication procedure.

[0088] In attack 700, attacker module 740 can retrieve or intercept code 730 from secure memory, but can only perform operations (1) and (2), but not action (3). Therefore, attacker module 740 cannot encode the changed secret sk' using encoding function 720 to obtain changed code (c') 750. Therefore, it is impossible to obtain a changed secret 770 related to the original secret 710. In the best case, the changed secret 770 has nothing to do with the original secret 710 and can be just an error message.

[0089] V. Decoding and verification of use

[0090] As part of ensuring that encoding cannot be performed using the available resources of the mobile device while allowing the mobile device to perform decoding functionality, embodiments may use constructions related to proof of space (also known as PoS), as described in [Ateniese et al., Proofs of space: When space is of the essence. In SCN, pp. 538-557, 2014; Dziembowski et al., Proofs of space. In CRYPTO, pp. 585-605, 2015].

[0091] In such instances, a component can use any input to construct a proof that allows for verification of computation without recomputing the entire function (i.e., verifiable computation). For example, if a function is executed on certain inputs to obtain a specific output, then verification can be performed to confirm that the function was computed correctly. This verification does not require as much memory as actually generating a specific output. Verification may instead take a proof and verify to confirm the computation of a specific output.

[0092] Thus, the prover P can prove that it has enough space available for a space-constrained verifier V. For example, a proof P can be presented for some secret X, for example using the Fiat-Shamir transform x [Fiat and Shamir. How to prove yourself: Practical solutions to identification and signature problems. In Crypto, pp. 186-194, 1986]. The verifier can verify the pair (X; p) in a restricted space, for example using less than S bits. x ). The code word is c = (X; p x ). Just by running p x The decoding is done by the checksum generated from X.

[0093] The soundness guarantee is that it is highly likely that a cheating prover will fail to produce a correct proof unless it uses a large amount of space, i.e., much more than S bits. The correctness guarantee is that if π S If it is indeed generated from X, then verification will be 1. The requirement of restricted verification is that verification requires at most S bits of memory to perform. If the codeword is stored in a device restricted by s, then decoding is possible within the available space, but encoding is not possible due to the soundness guarantee. Therefore, the only way to generate a valid codeword is to have the provisioned device overwrite an existing codeword.

[0094] The above technology can be implemented as:

[0095] SETUP→pp: Returns the random algorithm of the public parameter PP.

[0096] PROVE pp (X)→(p x ): accepts any challenge (secret) X as input and returns proof p x Deterministic algorithm.

[0097] VERIFY PP (X,p x )→0 / 1: A deterministic algorithm that accepts a challenge-proof pair as input and returns a decision bit 0 / 1 (p x The '0' is not generated from X, and p x The '1' is generated by X.

[0098] The setup function and the proof function are executed by the provisioning device. The setup function can be executed once for all proofs when the device is set up. After executing the proof function, the secret X, the proof p x The verification function may be performed by the mobile device as a decoding function. The codeword c may include (X, p x , PP) and stored in a secure element that includes a verification function. To execute a function F that operates on an input using a secret X (e.g., an encryption operation), a decoding function may parse X, p from a codeword C. x and PP, and use the verification function to determine whether the challenge-proof pair is valid (output = 1) or invalid (output = 0). If the challenge-proof pair is valid, then the function F X (input) provides output. If the challenge-proof pair is invalid, the secure element may provide an error message, e.g., ⊥.

[0099] In one technique, a setup function uses a local expander graph stack (SoLEG) to generate public parameters as a graph, and a proof function uses the graph to calculate the label of the graph and uses a Merkle commitment scheme to submit the resulting string (proof). Several challenge vertices of the graph are then randomly selected. For each challenged vertex, the prover calculates and outputs the openness to this vertex, as well as the openness to all predecessors of the vertex. The verifier obtains a secret (identity) and a proof as input, the secret and proof including the commitment and the openness. The verification function can verify the consistency of all opens relative to the commitment and check the local correctness of the label. SoLEG is an example of a memory-dependent function, but the construction of SoLEG in the proof function allows a lot of memory to be used for decoding. In contrast, an embodiment can apply a memory-dependent function before the proof function, thereby allowing decoding to be performed using a smaller amount of memory.

[0100] The labels of the graph require a lot of memory (space) according to the desired goal making the encoding require a lot of memory. The verification function uses less memory when checking the openness of only a few random challenge vertices. However, the above technique may require too much memory for the verification function to run properly on a mobile device, for example, requiring 30Mb or more of memory for the secure element to use.

[0101] As part of using less memory for decoding, embodiments may use computational verification instead of large space verification. PoS guarantees that the prover uses enough space, but does not guarantee anything about the computation. Specifically, if the encoding method used by the prover is different from the specified encoding method, but still uses a considerable amount of space, then the verification will be valid. In contrast, when verifying the calculation, the prover must use the specified encoding function to make the verification (decoding) valid. Specifically, if the prover uses a different encoding function, then the verification will fail even if a large amount of computational space is used.

[0102] VI. Use of memory-dependent functions

[0103] Embodiments provide encoding / decoding techniques in which the decoding function can be performed with less than s bits and the encoding function requires more than s bits (e.g., 10x, 100x, or 1000x). Specifically, embodiments may provide encoding / decoding techniques in which the amount of memory used for encoding is tens or hundreds of gigabytes (e.g., terabytes), while decoding requires only a few kilobytes. Thus, embodiments may improve upon the above techniques. Furthermore, this proposed construction may make the verification memory linear with the message size (security parameter) and therefore scalable.

[0104] In order to achieve the goal of executing the decoding function with less memory while maintaining the large memory requirement for the encoding function, a memory-dependent function can be implemented using the secret X as input and providing an output Y before executing the proof function. In one embodiment, Y = MHF(Hash(X)), where Hash is any standard hash function, such as SHA-256, and MHF is any standard memory-dependent function.

[0105] Given any input, the execution of a memory-dependent function may require at least a given amount of space. A memory-dependent function will require a certain number of bits. Example memory-dependent functions can be found, for example, at en.wikipedia.org / wiki / Scrypt or Biryukov et al., "Argon2: the memory-hard function for passwordhashing and other applications," available from password-hashing.net / argon2-specs.pdf. Memory-dependent functions can be proven to be memory-dependent in a random oracle model, and techniques for password hashing can be implemented.

[0106] Given that memory-dependent functions have limited the minimum amount of memory required, the proof function may not need to be complex, resulting in a decoding function that is not memory intensive. Verifiable computing techniques can be used, such as short, non-interactive proof of knowledge (SNARK) techniques. In some embodiments, Pinnocchio (eprint.iacr.org / 2013 / 279.pdf) can be used to implement the proof and verification functions, which uses less memory than the example provided in the previous section. This verifiable computing technique can verify whether the same encoding function is used, rather than verifying the amount of space used for the calculation. In addition, the verification procedure can be independent of the complexity of the calculation. Therefore, using space-intensive calculations does not change the space complexity of the verification.

[0107] A. Encoding method (provisioning server)

[0108] Figure 8 8 is a flow chart illustrating a method 800 for encoding a secret according to an embodiment of the present invention. The method 800 may be executed on an encoding computer, which may provision codewords to a mobile device. The method 800 may use a memory-dependent function as part of the encoding to ensure that the amount of memory required on the encoding device is minimized, and use verifiable computing techniques that allow memory-limited devices to perform decoding, while still providing a mechanism for identifying tampering.

[0109] At block 810, one or more public parameters are retrieved, wherein the one or more public parameters are generated based on a memory dependent function F and a security parameter λ. The generation of the one or more public parameters may be performed by a setup function, e.g., depicted as VC.SETUP(F)→pp, where pp corresponds to the one or more public parameters. In some embodiments, a plurality of public parameters may be generated, including a first parameter and a second parameter, which are different parameters. As an example, the public parameters may include an evaluation key (EK_F) that the prover may use later. This evaluation key EK_F may depend on F. Another key VK_F used for verification may also depend on F. The calculation may depend on the security parameter. A security setup of approximately 128 bits may be used.

[0110] At box 820, a memory-dependent function MHF is applied to a secret S or a function of S (e.g., a hash) to obtain a result Y. Applying the memory-dependent function F to the secret S may require at least N bytes of memory on the encoding computer. As an example, N may be at least one gigabyte (e.g., 2GB, 5GB, 10GB, 100GB, etc.). In some embodiments, N may be set by adjusting security parameters and other system parameters. In some embodiments, the memory-dependent function MHF may be applied to a hash function H (e.g., output Z) applied to the secret S, such that the memory-dependent function (MHF) acts on the output Z of the "hash function". The MHF may also include a hash. The hash function H may make H(x) random for any X. In some embodiments, F(S) is determined using one of the one or more public parameters, such as the evaluation key EK_F described below. More than one parameter may also be used to determine F(S).

[0111] At block 830, the proof function uses the secret S, the result Y, and one of the one or more public parameters to determine a proof value π. The proof value π is verifiable and can therefore be used to verify S and Y (e.g., to verify that they have not been tampered with). The provide function can be depicted as VC.PROVE pp (S,F)→π.

[0112] At block 840, a codeword C is assembled based on the proof value π, the secret S, the result Y, and at least one of the one or more public parameters. The codeword C can be depicted as C:=(S, Y, π). In some embodiments, a second parameter in the public parameters can be used in block 840, and a different first parameter can be used in block 830. In other embodiments, the same public parameter can be used in both blocks. The proof value π can have a constant size. The public parameters can be permanently hard-coded into the device, for example, because the public parameters are the same for all codewords and cannot be tampered with. The public parameters can be located outside the device, for example, stored in a trusted server. The proof function and the verification function can access the public parameters when needed.

[0113] At block 850, the codeword C is sent to a device configured to store the codeword C and later decode the codeword C. The proof value π is configured to be used by a decoding function of the device to verify the correctness of a stored result Y obtained from a memory-dependent function F using a secret S. The decoding function is operable to use K bytes of memory. As examples, K may be at least 100, 200, 500, or 1000 times smaller than N. For example, K may be hundreds (e.g., 500) or tens or hundreds of thousands (e.g., 10 kB, 50 kB, 100 kB, or 500 kB).

[0114] Thus, the decoding function can still be performed by a device with limited memory, such as a mobile device. Also, an improvement is the ability to decode (e.g., verify) using a relatively small amount of memory, which enables decoding on a mobile device while still maintaining the inability to perform encoding on the mobile device. Furthermore, in embodiments where decoding is performed in the secure element, it is difficult to add more memory, such as by connecting the mobile device to another device with additional memory and processing power.

[0115] In various embodiments, the decoding function may be or include a verification function and may therefore include other functionality in addition to verification. Verification may be depicted as VC.VERIFY pp (S,Y,π)→0 / 1. If Y is equal to F(S), then the verification function will output 1; if it is not equal to F(S), then it will output 0. The completeness requirement ensures that if the proof is generated correctly, then it must verify correctly. The soundness requirement ensures that if y ≠ F(x), then the proof should not verify correctly. If VC.VERIFY requires s bits of memory to execute, then VC.VERIFY can be considered to be restricted by s.

[0116] B. Example of encoding / decoding scheme

[0117] Fig. 9An example encoding / decoding scheme 900 using a hash function according to an embodiment of the present invention is shown. In this example, function F includes an initial hash function H (which is applied to a secret x) and a memory-dependent function (MHF). This example corresponds to a block. Steps 920 and 930 (including sub-steps 931-934) can be performed by a provisioning device, and step 940 can be performed by a verification device, such as a user device that can be moved. Step 940 can be performed in a secure element of the verification device.

[0118] At 910, a function F is defined to include a memory dependent function (MHF) and a hash function H, where the hash function H is applied first.

[0119] At 920, the setup function determines one or more public parameters PP. The setup function may determine PP using a function F. Details of the setup function may be found in Pinnocchio (eprint.iacr.org / 2013 / 279.pdf).

[0120] At 930, a proof function is used to generate a codeword C, including a proof value corresponding to the secret X. As shown, the proof function is implemented as follows. At 931, a hash function H is applied to the secret X to obtain a hash Z. A hash function can be performed using various techniques, such as a hash table, a trivial hash function, a perfect hash, a minimal perfect hash, a hash uniformly distributed data or other distribution, a rolling hash, a universal hash, a multiplication hash, and a cryptographic hash function. The hash function can map the secret H to a hash of a fixed size, and can be a one-way hash function. The hash function H may have a deterministic property, so that the same message always produces the same hash, it is impossible to generate a message from the hash value of the message, except that a small change in the message should widely change the hash value, so that the new hash value becomes independent of the old hash value, and it is impossible to find two different messages with the same hash value. The hash function can be used as a random function (commonly known as a random oracle model) and can be instantiated with a cryptographic hash function. An example hash function is SHA-256.

[0121] At 932, a memory dependency function MHF is applied to the hash Z to obtain a result Y. At 933, a VC.Prove function is applied to the secret X and the result Y to determine the proof π using at least one public parameter. At 934, a codeword C is assembled to include the secret X, the result Y, the proof π, and the at least one public parameter PP. The codeword C can be sent to a verification device, such as a device that uses the secret X for cryptographic purposes.

[0122] At 940, the verification function verifies the codeword C. The codeword C may be parsed to determine the secret X, the result Y, the proof π, and the at least one public parameter PP separately. The verification function may then use the proof π to confirm that the result Y was determined by applying the function F to the secret X. If X, Y, the proof π, or the at least one public parameter PP is altered, then the verification will be false.

[0123] In some embodiments, when the verification is true, a cryptographic function may be applied to the input data using the secret S to obtain output data output from the security element of the verification device. When the correctness is false, an error message may be provided. Thus, the result of the verification may indicate additional functionality of the verification device, for example, whether the security element of the mobile device is to encrypt the input data using the secret X.

[0124] Fig.10 An example encoding / decoding scheme 1000 using publicly verifiable calculations according to an embodiment of the present invention is shown. Scheme 1000 uses two public parameters: a public evaluation key and a public verification key. Key generation (KeyGen) is performed as a setup function. The calculation function performs encoding. And, the verification function is decoding. Fig.11 Shown from Fig.10 A depiction of the encoding / decoding scheme.

[0125] At 1010, key generation uses a security parameter λ and a function F. In some embodiments, function F may include multiple parts, such as an initial hash function applied to the hash result and a memory-dependent function, such as Fig. 9 As shown. Use the security parameter λ and function F to generate the public evaluation key EK F and the public verification key VK F This key generation can be performed just like in Pinnocchio. Fig.11 The setup function 1110 corresponds to the key generation in 1010.

[0126] At 1020, using the secret X and the public evaluation key EK F As input. Function F uses secret X to determine result Y. Then, the proof function can use secret X and result Y to obtain proof of correctness π y Steps 1010 and 1020 may be performed by a pre-configured device having sufficient memory to perform the encoding. The pre-configured device may store the data including X, Y, π y and VK F The codeword X is sent to a user device, which can use the secret X for cryptographic purposes.

[0127] Fig.11 The encoding function 1120 corresponds to the computation function 1020. Using the secret X and the public evaluation key EKF Calculate F to obtain the result Y and prove π y Then use the secret X, the result Y and the proof π y Assembly code C.

[0128] At 1030, the verification function can use the codeword to confirm whether the result Y is indeed the result obtained using π y and VK F Generated from secret X. Decoding function 1130 corresponds to 1030. Decoding can be performed by a pre-configured device, such as a phone. The codeword can be parsed to obtain secret X, result Y, and proof π y The verification function can then use the public verification key VK F And prove π y To verify that the application of function F to secret X is indeed Y.

[0129] VII. Device

[0130] The provisioning device and the mobile device are now described.

[0131] A. Pre-configured device

[0132] Fig.12 1 shows a block diagram of a provisioning apparatus 1200 according to an embodiment. The modules of the provisioning apparatus 1200 may be implemented in hardware or software, for example, stored in a computer-readable medium and executed by a processor. The provisioning apparatus 1200 includes a data storage device 1205, a parameter generation module 1210, a memory dependency module 1212, a proof generation module 1214, an encoding module 1216, a communication module 1218, and a network interface 1230. The provisioning apparatus 1200 may implement the method 800, including Figure 8-11 The scheme described in .

[0133] The data storage 1205 may store the secret S to be encoded and the security parameter λ. The data storage may be implemented in various ways, for example, in a cache of a processor, RAM, flash memory, or a hard drive.

[0134] The parameter generation module 1210 may receive the security parameter λ and information about the function F to be used (including the memory dependent function MHF) (e.g., an identifier indicating which memory dependent function to use or some parameters of F). The parameter generation module 1210 may generate one or more public parameters PP based on the memory dependent function F and the security parameter λ. Other modules may also use the security parameter λ. In some embodiments, various aspects of the function F may be hard-coded into the parameter generation module 1210, and therefore no information needs to be sent from the data 1205. The one or more public parameters PP may include a key, for example, Fig.10 and 11Thus, the parameter generation module 1210 may be a key generation module that verifies computation. Once one or more public parameters provided previously are generated, they may be stored for access by other modules and other devices, for example, for public access.

[0135] The memory dependency module 1212 may implement a memory dependency function F that requires the memory 1220 to be of sufficient size. The data storage device 1205 may be part of the memory 1220 and may therefore be the same memory structure. The memory dependency module 1212 may receive one or more public parameters PP and a secret S and provide a result Y, which may be used to generate a proof. The memory dependency module may include other functions in addition to the memory dependency function F, such as the initial hash function described herein.

[0136] The proof generation module 1214 may receive a secret S and a result Y, where Y is produced by the operation of the memory-dependent module on the secret S. The proof generation module 1214 provides a proof π that can be used to effectively verify whether Y is indeed the result of applying the memory-dependent function F to the secret S. The corresponding decoding function can perform such verification.

[0137] The encoding module 1216 may receive the proof π and the result Y and the secret S used to form the code C. The code C may be provided to the communication module 1218, which may place the code C into a message (e.g., an encrypted message) sent by the network interface 1230 to the mobile device 1240. The communication module 1218 may use any suitable network protocol that may be present in a wired connection, such as TCP / IP or Ethernet. Once provisioned, the mobile device 1240 may store the code C in a secure element and decode C to implement cryptographic functionality. The decoding function using the proof π may be concise enough so that the decoding may be performed on the mobile device, for example, in a secure element that may only have 1 kB, 50 kB, 100 kB, 500 kB, or 1 kB of memory.

[0138] B. Mobile devices

[0139] Fig.13 A method 1300 is shown illustrating a decoding process using a codeword for use in a cryptographic function according to an embodiment of the present invention. The method 1300 may be performed by a mobile device or other authentication device, particularly a device with limited memory. For example, a secure element of the device may have limited memory.

[0140] At block 1310, a secure memory stores a codeword C. The codeword C may include a proof value π, a secret S, and a result Y obtained by applying a memory-dependent function F to the secret S. Applying the memory-dependent function MHF to the secret S or a function of the secret S may require at least N bytes of memory. N may be at least one gigabyte.

[0141] At block 1320, input data may be received, for example, at a secure element. The secure memory may be part of the secure element. The secure element may perform method 1300. As an example, the input data may include a message to be encrypted before being sent to a recipient.

[0142] At block 1330, codeword C is retrieved from secure memory.

[0143] At block 1340, the codeword C is parsed to identify the proof value π, the secret S, and the result Y. Additional one or more public parameters used by the memory-dependent function MHF to obtain the result Y may be retrieved.

[0144] At block 1350, codeword C is decoded by using the proof value π to verify the correctness of the stored result Y obtained by applying the memory-dependent function F to the secret S. The decoding is operable to use K bytes of memory. K may be at least 100 times smaller than N.

[0145] At block 1360 , when correctness is true, a cryptographic function may be applied to the input data using the secret S to obtain output data output from the secure element.

[0146] At block 1370, when the correctness is false, an error message may be provided, for example, a value may be output.

[0147] Fig.14 A block diagram of a mobile device 1400 according to an embodiment is shown. Mobile device 1400 may send a request for an encoded secret, for example as code C. The provisioning computer may send a response with code C to mobile device 1400, which may store code C in secure memory 1450. Mobile device 1400 is an example of a decoding computer.

[0148] The mobile device 1400 includes a processor 1410, a computer readable medium 1420 (e.g., for storing software to be executed on the processor 1410), an input / output component 1430 (e.g., a touch screen, a microphone, and a loudspeaker), a communication module 1440, a secure memory 1450, and a secure element 1460, each of which can be connected to a communication bus for mutual communication. In some embodiments, the secure memory 1460 can include the secure element 1450.

[0149] The communication module 1440 may receive the codeword C via the antenna 1470. The secure memory 1450 may store the codeword C, which includes the proof value π, the secret S, the result Y obtained by applying the memory-dependent function F to the secret S, and one or more public parameters used by the memory-dependent function F to obtain the result Y. The memory-dependent function F may be implemented by a provisioned computer, where applying the memory-dependent function F to the secret S may require at least N bytes of memory. As an example, N may be at least one gigabyte.

[0150] As shown, the security element 1460 includes a parsing module 1461, a decoding module 1462, a decision module 1463, and a cryptographic module 1464. The security element 1460 can receive input data and perform a cryptographic function on the input data. The parsing module 1461 can retrieve a codeword C from the secure memory 1450 and parse the codeword C to identify the proof value π, the secret S, the result Y, and one or more public parameters.

[0151] The decoding module 1462 may decode the codeword C using the proof value to verify the correctness of the stored result Y obtained by applying the memory-dependent function F to the secret S. The decoding module 1462 may be operable to use K bytes of memory. As an example, K may be at least 100 times smaller than N. The decoding module 1462 may output whether the correctness has been verified (true) or not verified (false).

[0152] Decision module 1463 can use the output from decoding module 1462 to determine whether to output an error message or to engage cryptographic module 1464. When correctness is true, cryptographic module 1464 can be applied to input data using secret S to obtain output data output from the security element. When correctness is false, an error message can be output from security element 1460.

[0153] VIII. Example Computer System

[0154] Any computer system mentioned herein may utilize any suitable number of subsystems. Fig.15 An example of such a subsystem in computer system 10 is shown in FIG. In some embodiments, the computer system includes a single computer device, wherein the subsystem may be a component of the computer device. In other embodiments, the computer system may include multiple computer devices with internal components, each of which is a subsystem. The computer system may include desktop and laptop computers, tablet computers, mobile phones, and other mobile devices.

[0155] Fig.15The subsystems shown in FIG. 1 are interconnected via a system bus 75. Additional subsystems are shown such as a printer 74, a keyboard 78, one or more storage devices 79, a monitor 76 coupled to a display adapter 82, and the like. Peripheral devices and I / O devices coupled to an input / output (I / O) controller 71 may be connected to the computer system through various means known in the art, such as an input / output (I / O) port 77 (e.g., USB, ). For example, I / O port 77 or external interface 81 (e.g., Ethernet, Wi-Fi, etc.) can be used to connect computer system 10 to a wide area network (e.g., the Internet), a mouse input device, or a scanner. Interconnection via system bus 75 allows central processor 73 to communicate with each subsystem and control the execution of multiple instructions from system memory 72 or one or more storage devices 79 (e.g., fixed disks, such as hard drives or optical disks), as well as information exchange between subsystems. System memory 72 and / or one or more storage devices 79 can embody computer readable media. Another subsystem is a data collection device 85, such as a camera, microphone, accelerometer, etc. Any data mentioned in this article can be output from one component to another component and can be output to a user.

[0156] The computer system may include multiple identical components or subsystems, which are connected together, for example, through external interface 81, through internal interface or via removable storage devices, which can be connected and removed from one component to another component. In some embodiments, the computer system, subsystem or device can communicate through a network. In such cases, one computer can be considered a client and another computer can be considered a server, each of which can be part of the same computer system. The client and server can each include multiple systems, subsystems or components.

[0157] Various aspects of the embodiments may be implemented using hardware circuits (e.g., application specific integrated circuits or field programmable gate arrays) and / or in a modular or integrated manner with a substantially programmable processor using computer software in the form of control logic. As used herein, a processor may include a single-core processor, a multi-core processor on the same integrated chip, or multiple processing units on a single circuit board or networked, as well as dedicated hardware. Based on the disclosure and teachings provided herein, one of ordinary skill in the art will know and appreciate other ways and / or methods of implementing embodiments of the present invention using hardware and combinations of hardware and software.

[0158] Any software components or functions described in this application may be implemented as software code executed by a processor using any suitable computer language such as Java, C, C++, C#, Objective-C, Swift, or a scripting language such as Perl or Python using, for example, conventional or object-oriented techniques. The software code may be stored as a series of instructions or commands on a computer-readable medium for storage and / or transmission. Suitable non-transitory computer-readable media may include random access memory (RAM), read-only memory (ROM), magnetic media such as a hard drive or floppy disk, or optical media such as a compact disk (CD) or a digital versatile disk (DVD), flash memory, etc. The computer-readable medium may be any combination of such storage devices or transmission devices.

[0159] Such programs can also be encoded and transmitted using carrier signals, which are suitable for transmission via wired, optical and / or wireless networks that meet multiple protocols, including the Internet. Therefore, a data signal encoded with such programs can be used to create a computer-readable medium. The computer-readable medium encoded with program code can be packaged with compatible devices or provided separately from other devices (for example, downloaded via the Internet). Any such computer-readable medium can reside on or inside a single computer product (for example, a hard drive, a CD or an entire computer system), and can be present on or inside different computer products in a system or network. A computer system can include a monitor, a printer or other suitable display for providing any result mentioned herein to a user.

[0160] Any method described herein may be performed in whole or in part by a computer system, and the computer system includes one or more processors that can be configured to perform the steps. Therefore, an embodiment may be related to a computer system configured to perform the steps of any method described herein, and may have different components that perform the corresponding steps or corresponding step groups. Although presented as numbered steps, the steps of the method herein may be performed simultaneously or at different times or in different orders. In addition, the parts of these steps may be used together with the parts of other steps of other methods. In addition, all or part of the steps may be optional. In addition, any step of any method may be performed using other components of the module, unit, circuit or system for performing these steps.

[0161] The specific details of a particular embodiment may be combined in any suitable manner without departing from the spirit and scope of the embodiments of the invention. However, other embodiments of the invention may be directed to specific embodiments relating to each individual aspect or specific combinations of these individual aspects.

[0162] The above description of example embodiments of the present invention has been presented for purposes of illustration and description. It is not intended to be exhaustive or to limit the invention to the precise form described, and many modifications and variations are possible in light of the above teaching.

[0163] Unless specifically indicated to the contrary, the recitation of "a", "an" or "the" is intended to mean "one or more". Unless specifically indicated to the contrary, the use of "or" is intended to mean "inclusive or" rather than "exclusive or". Reference to a "first" component does not necessarily require that a second component be provided. Moreover, unless explicitly stated, reference to a "first" or "second" component does not limit the referenced components to specific locations. The term "based on" is intended to mean "based at least in part on".

[0164] All patents, patent applications, publications, and descriptions mentioned herein are incorporated by reference in their entirety for all purposes. No admission is made that they are prior art.

Claims

1. A method for encoding a secret, the method comprising performing the following operations on an encoding computer: Retrieving one or more public parameters generated based on the memory dependency function MHF and a security parameter λ, wherein the security parameter λ is specified according to a required security level; applying the memory-dependent function MHF to a secret S or a function applied to the secret S to obtain a result Y, wherein applying the memory-dependent function MHF to the secret S or a function applied to the secret S requires at least N bytes of memory on the encoding computer, N being at least one gigabyte; Using a proof function, determine a proof value π using the secret S, the result Y, and the one or more public parameters; Assembling a codeword C according to the proof value π, the secret S and the result Y, so that the codeword C includes the proof value π, the secret S and the result Y; as well as The codeword C is sent to a device configured to store the codeword C and to decode the codeword C using the proof value π upon receiving input data to verify the correctness of the result Y, the result Y being included in the codeword C and being obtained by applying the memory-dependent function MHF to the secret S or to a function of the secret S, wherein the decoding function is operable to use K bytes of memory, K being less than N, wherein when the correctness of the result Y is true, the device is configured to apply a cryptographic function to the input data using the secret S to obtain output data, and when the correctness of the result Y is false, the device is configured to provide an error message.

2. The method of claim 1, wherein K is at least 100 times smaller than N. The method of claim 1 , wherein the one or more public parameters include a public evaluation key. The method according to claim 3 , wherein the public evaluation key is used to generate the proof value π and the result Y. The method according to claim 1 , wherein the memory dependency function (MHF) comprises a hash function.

6. The method according to claim 1, wherein the memory dependency function MHF is applied to the function of the secret S, and wherein the function of the secret S is a hash function.

7. The method of claim 1, wherein N is at least one terabyte.

8. The method of claim 1, wherein the decoding function requires less than 1 MB of memory.

9. A method for decoding a secret, the method comprising performing the following operations on a decoding computer: storing a codeword C comprising a proof value π, a secret S and a result Y obtained by applying a memory-dependent function MHF to the secret S or to a function applied to the secret S, wherein applying the memory-dependent function MHF to the secret S or to a function applied to the secret S requires at least N bytes of memory, N being at least one gigabyte; Receive input data; Retrieving the codeword C; Parsing the codeword C to identify the proof value π, the secret S, the result Y, and one or more public parameters, wherein the one or more public parameters are generated based on the memory-dependent function MHF and a security parameter λ, wherein the security parameter λ is specified according to a desired security level; The decoding of the codeword C is performed by the following operations: using said proof value π to verify the correctness of said result Y included in said codeword C and obtained by applying said memory-dependent function MHF to said secret S or to a function of said secret S, wherein said decoding is operable to use K bytes of memory, K being less than N; When said correctness of said result Y is true, applying a cryptographic function to said input data using said secret S to obtain output data; as well as When the correctness of the result Y is false, an error message is provided.

10. The method of claim 9, wherein K is at least 100 times smaller than N. The method of claim 9 , wherein the one or more public parameters include a public authentication key.

12. The method of claim 11, wherein the decoding uses the public authentication key.

13. The method of claim 9, wherein the decoding requires less than 1 MB of memory.

14. The method according to claim 9, further comprising: The codeword C is received from a provisioning computer, which generates the proof value π and the result Y by applying the memory-dependent function MHF to the secret S.

15. The method of claim 9, wherein the codeword C is stored in a secure memory, and wherein a secure element performs the decoding of the codeword C and the application of the cryptographic function.

16. A computer product comprising a computer readable medium storing a plurality of instructions for controlling a computer system to execute the method according to any one of claims 1 to 15.

17. An apparatus comprising: a secure memory storing a codeword C comprising a proof value π, a secret S and a result Y obtained by applying a memory-dependent function MHF to the secret S or to a function applied to the secret S, wherein applying the memory-dependent function MHF to the secret S or to a function applied to the secret S requires at least N bytes of memory, N being at least one gigabyte; as well as A security element configured to: Receive input data; Retrieving the codeword C; Parsing the codeword C to identify the proof value π, the secret S, the result Y, and one or more public parameters, wherein the one or more public parameters are generated based on the memory-dependent function MHF and a security parameter λ, wherein the security parameter λ is specified according to a desired security level; The decoding of the codeword C is performed by the following operations: using said proof value π to verify the correctness of said result Y included in said codeword C and obtained by applying said memory-dependent function MHF to said secret S or to a function of said secret S, wherein said decoding is operable to use K bytes of memory, K being less than N; When the correctness of the result Y is true, applying a cryptographic function to the input data using the secret S to obtain output data output from the secure element; as well as When the correctness of the result Y is false, an error message is provided.

18. The device of claim 17, wherein the device is mobile. The apparatus of claim 17 , wherein the secure element comprises the secure memory.

20. The apparatus of claim 17, wherein K is at least 100 times smaller than N.

21. The apparatus of claim 17, wherein the one or more public parameters include a public authentication key.

22. The apparatus of claim 21, wherein the decoding uses the public authentication key.

23. The apparatus of claim 17, wherein the decoding requires less than 1 MB of memory.

24. A computer system comprising: processor; as well as A computer readable medium comprising codes, the codes being executable by the processor to cause the processor to perform the method according to any one of claims 1 to 15.

Images