Patent Description:
The systems, methods and apparatuses described herein relate to the security of data communication between electronic devices, and in particular, ensuring that a computing device with which a connection is established is a trusted and secure device.

Device attestation provides assurance that a physical device such as a computer, smartphone or tablet, is a trusted and secure device. In conventional device attestation, each device is given a unique private key, which is then attested one way or another (usually by involving a third party). Unfortunately, in many cases, this unique private key (and/or associated public key cryptography) may be prohibitively expensive to deploy and in many other cases, the "third party" requirement becomes inconvenient. In some other device attestations known in the art (such as High-bandwidth Digital Content Protection (HDCP)), attestation is based on one single key common for all devices, and as soon as this single key is extracted (and potentially published), such attestation becomes insecure.

In addition, conventional attestation methods (based on device private key) can be circumvented by extracting the private key from the device and running a software emulator using this extracted private key.

Therefore, there is a need in the art for device attestation that eliminates the private device key and the third party attestation service, while avoiding relying on the single shared key. Additionally, there is a need for device attestation that can complement the conventional attestation methods to prevent an attacker from using purely software emulators even if the private key of the device has been extracted by the attacker.

<CIT> relates to originator authentication using platform attestation. An originator device allows for a unique passphrase to be communicated to a service system. The originator device has a fixed token in which a unique platform identifier is recorded and a processor to generate a representation of the platform configuration. This representation is communicated to the registry service as a unique, platform-specific passphrase associated with the originator.

<CIT> relates to a method for activating and executing protected functions in a communication system. In a communication system having a function or performance feature to be protected, the periodic transmission of encoded interrogation information is initiated by a security routine to ensure that the function or performance feature is protected. The protected function is activated and further-executed only if reply information which is also encoded is received from a connected crypto-unit in a predetermined time span after a transmission of the interrogation information.

<CIT> relates to a method and apparatus for checking proximity between devices using hash chain. Described is a method of measuring round trip time (RTT) including: chain-hashing at least one random number to create a plurality of hash values; transmitting one of the created hash values to a device and starting to measure RTT of the device; and receiving from the device a response to the transmitted hash value and ending the RTT measurement, thereby performing a more effective proximity check than a conventional proximity check requiring encryptions and decryptions of several tens of times through several thousands of times.

The present invention relates to a computing device for attesting a communication partner according to independent claim <NUM> and to a method for attesting a computing device to a communication partner according to independent claim <NUM>. Preferred embodiments are defined in the related dependent claims.

Certain illustrative aspects of the systems, apparatuses, and methods according to the present invention are described herein in connection with the following description and the accompanying figures. These aspects are indicative, however, of but a few of the various ways in which the principles of the invention may be employed and the present invention is intended to include all such aspects and their equivalents. Other advantages and novel features of the invention may become apparent from the following detailed description when considered in conjunction with the figures.

In other instances, well known structures, interfaces, and processes have not been shown in detail in order not to unnecessarily obscure the invention. However, it will be apparent to one of ordinary skill in the art that those specific details disclosed herein need not be used to practice the invention and do not represent a limitation on the scope of the invention, except as recited in the claims. It is intended that no part of this specification be construed to effect a disavowal of any part of the full scope of the invention. Although certain embodiments of the present disclosure are described, these embodiments likewise are not intended to limit the full scope of the invention.

The present disclosure provides systems, methods and apparatuses for secure data communication between electronic devices, and in particular, ensuring the communication is between intended and/or verified devices. In certain aspects, a method according to the present disclosure may comprise generating a message, sending the generated message to a communication partner and starting to count time. The message may comprise computation parameters for computation to be performed at the communication partner. The method may further comprise receiving a value returned from the communication partner, determining whether the value is returned within a predefined or predetermined time threshold, and determining whether the received value is an expected value. The predefined or predetermined time threshold may be selected to ensure that the computation is performed by a dedicated computation module at the communication partner. If both tests succeed, the method may determine that the communication partner is a trusted device. If either test fails, the method may determine that the communication partner is not a trusted device.

In other aspects, a method according to the present disclosure may comprise determining the time needed for round-trip data transmission between two electronic devices. The round-trip data transmission may include transmitting data to a communication partner and receiving an echo from the communication partner. The method may further comprise selecting computation parameters based on the determined time, generating a message that includes the parameters, sending the generated message to a communication partner and starting to count time. The computation parameters may be input parameters for computation to be performed at the communication partner. The method may further comprise receiving a value returned from the communication partner, determining whether the value is returned within a predefined or predetermined time threshold, and determining whether the received value is an expected value. The time threshold may be selected to ensure that the computation is performed by a dedicated computation module at the communication partner. If both tests succeed, the method may determine that the communication partner is a trusted device. If either test fails, the method may determine that the communication partner is not a trusted device.

Without being limiting, <FIG> shows an exemplary system <NUM> according to the present disclosure. The system <NUM> may comprise a server <NUM> and a computing device <NUM>. The server <NUM> may be coupled to the computing device <NUM> by a communication link <NUM>. The server <NUM> may be a computing device that comprises one or more computer processors and may want to ensure that the computing device <NUM> is a trusted device. The communication link <NUM> may be of any type, including, for example wired (e.g., USB, Ethernet, IEEE <NUM>, etc.), wireless (e.g., Near Field Communication, WiFi, Bluetooth, etc.), direct or through the Internet, etc..

The computing device <NUM> may comprise a specially designed and built dedicated computation module <NUM> for performing a predefined function F. The function F may be selected from a group such that performance of the function F on a commonly available general purpose computing device (e.g., a general-purpose CPU, a GPU or field-programmable gate array (FPGA) integrated circuits) may take a much longer time (for example, at least twice or more) than it would on the dedicated computation module <NUM>.

In one non-limiting embodiment, the function F may be selected such that its computation may be sequential (e.g., a series of computation steps in a sequence). That is, the computation result cannot be obtained faster by splitting the computation process into parts and performing one or more parts in parallel. For example, using an initial value V<NUM> as an input parameter, a hash function H may be computed to obtain value V<NUM> (e.g., V<NUM> = H(V<NUM>)). The hash function may be any suitable hash function such as, for example, SHA-<NUM>, SHA-<NUM>, or SHA-<NUM>. Then the hash function H may be applied to the value V<NUM> to obtain V<NUM> (e.g., V<NUM> = H(V<NUM>)). Such a process may be repeated N times (wherein N may be any integer greater than one) to obtain a resulting value VN, wherein VN = H(VN-<NUM>). The function F in such an embodiment may be the entire process of calculating VN from V<NUM>. Because getting the result of each step requires a result of the previous step, the computation of the function F may be considered sequential.

In another non-limiting embodiment, a symmetric encryption algorithm E may be used in calculating a sequential function F. The symmetric encryption algorithm E may be any suitable symmetric encryption algorithm such as, for example, the Advanced Encryption Standard (AES) algorithm. In such an embodiment, the server <NUM> may send to the computing device <NUM> two pieces of data, an encryption key K and a value V<NUM>. Alternatively, the device <NUM> may already have an encryption key K (because, for example, it was stored in the device at the time of manufacture or it was sent to the device at an earlier time) and the server <NUM> may send to the computing device <NUM> only a value V<NUM>. The computing device <NUM> may use the encryption key K and the value V<NUM> as the parameters for the symmetric encryption algorithm E to obtain a value V<NUM> (e.g., V<NUM> = E (K, V<NUM>). V<NUM> may be calculated by using the encryption key K and V<NUM> as the parameters for the encryption algorithm E. The process may similarly be repeated N times (wherein N is any integer greater than <NUM>) to obtain VN, whereby VN = E (K, VN-<NUM>). That is, the symmetric encryption key K sent by the server <NUM> may be repeatedly used for the encryption calculation but each time encrypting a previous encryption result (with the exception of the first time that uses the initial value sent by the server <NUM>). In yet another non-limiting embodiment, an asymmetric encryption algorithm A, for example the Rivest-Shamir-Adleman (RSA) algorithm or Elliptic Curve Cryptography (ECC), may be used instead of a symmetric encryption algorithm E to calculate the sequential function F.

In some embodiments, the initial value V<NUM> may be a number that is hard to predict. For example, it may be a randomly generated large number.

In embodiments in which the function F is computed sequentially, the function or algorithm performed at each step of the sequential function (e.g., the hash function H, the symmetric encryption algorithm E, etc.) may be selected such that the output of the function or algorithm at the step has a number of possible values that is equal to or greater than a predefined number of values (for example, but not limited to, equal to or greater than <NUM><NUM> values). For example, if a hash function H is used to calculate each step of the sequential function F, using the SHA-<NUM> hash function will provide an output at each step of the sequential function F that has <NUM><NUM> possible values. As another example, if the symmetric encryption algorithm E used at each step of the sequential function is the AES algorithm, the AES algorithm may be run twice at each step of the sequential function F to obtain an output with <NUM><NUM> possible values.

Additionally, in embodiments in which the function F is computed sequentially, the function or algorithm performed at each step of the sequential function F (e.g., the hash function H, the symmetric encryption algorithm E, etc.) may be selected to have the property wherein each output value of such a function or algorithm would have approximately the same probability to occur if the input values are selected at random from among all possible input values. For example, those functions that provide a one-to-one correspondence between its input and output (such as, for example, some implementations of encryption algorithms, multiplication by a certain constant in Galois field, or linear congruential generators that satisfy the requirements of the Hull-Dobell theorem) may have this property. Also, cryptographic hash functions (for example, SHA-<NUM>, SHA-<NUM>, etc.) may also have this property (in cryptography, with respect to hash functions, this property is sometimes referred to as the "avalanche effect").

It is to be recognized that, if the function F is computed sequentially, it is not required that the same function or algorithm be used at each step of the sequence. By way of example and not limitation, a sequential function F may comprise alternating between performing a hash function H and an encryption algorithm E at each step of the sequential function. Of course, the various functions or algorithms used at each step of the sequential function F may be combined in any manner or order.

The dedicated computation module <NUM> may be, for example, an Application-Specific Integrated Circuit (ASIC) favoring speed of processing or any other dedicated hardware. For example, an ASIC implementation may be approximately a few times faster than a corresponding field programmable gate arrays (FPGAs) implementation. The ASIC (or any other dedicated hardware) implementation may also be much faster than software emulations using the combinations of general purpose CPUs and/or graphical processing units (GPUs). It is known in the art that dedicated hardware (including ASIC) implementations tend to be significantly faster (such as <NUM> times faster) than FPGA counterparts. It is further known in the art that dedicated hardware (including ASIC) implementations tend to be significantly faster than CPU/GPU implementations; for example, when INTEL has introduced hardware-based support for Advanced Encryption Standard (AES) Instruction Set (as hardware-supported AES-NI instructions), it improved performance of AES algorithm by approximately <NUM> to <NUM> times compared to implementations without AES-NI.

In some embodiments, the dedicated computation module <NUM> may be implemented as a special instruction for a CPU (not shown) that runs on the device <NUM>. In this case, however, access to this special instruction may be restricted only to programs that perform attestation of this specific device (for example, such programs may be signed by a trusted third party), and only as a part of an attestation protocol (for example, as described below with respect to <FIG>). Allowing such a special instruction to be used in an indiscriminate way may allow this special instruction to be used in processing requests intended for other devices, which may compromise the attestation schema. Therefore, in some embodiments, using non-restricted special instructions (such as AES-NI) for attestation described in present embodiment, may be inadvisable.

In some embodiments, the function F may be selected such that the amount of work necessary for its computation depends on its parameters. For example, in the above examples, the number of rounds N may be a variable with its value generated at the server <NUM>, and communicated from the server <NUM> to the device <NUM>. In other words, both N and V are parameters of the function F to be sent from the server <NUM> to the computing device <NUM>. The greater the number N, the more rounds that need to be calculated and, therefore, the greater the amount of computation work that needs to be performed. Further, in some embodiments, the function F may be selected such that to start its computation all bits of the input parameter V<NUM> are necessary (thus preventing the start of calculations before the entire value V<NUM> is received at the device <NUM>), and all the bits constituting the output of the function F are obtained simultaneously (thus preventing an attacker or malicious device from guessing the first several bits and using the time saving in computing the remaining bits).

<FIG> illustrates an exemplary process <NUM> that may be implemented by the server <NUM> to determine whether the computing device <NUM> is a trusted and secure device. The process <NUM> may start at block <NUM>, at which the computing device <NUM> and the server <NUM> may establish a communication channel (such as, for example, a TCP channel) over the communication link <NUM> to communicate data. Details of establishing such a communication channel may vary, in particular, such details may depend on the particular type of communication link <NUM> and are well-known to those with ordinary skill in the art. In some embodiments, the communication channel may be a secure channel, such as a secure socket layer or transport layer security (SSL/TLS) channel, established over the communication link <NUM>.

The process <NUM> may proceed to block <NUM>, at which a message may be generated. The message may include parameters that may be used by the dedicated computation module <NUM> of the device <NUM> to calculate the function F. For example, the server <NUM> may use a random number generator (for example, cryptographically safe random number generator) to generate a nonce as the initial value V<NUM>. Optionally, a variable N may also be generated as another parameter to indicate the number of iterations to be performed by the computing device <NUM>. The nonce (V<NUM>), and optionally the variable N, may be parameters to be included in the generated message. At block <NUM>, the generated message may be sent to the computing device <NUM> and the server <NUM> may start to count the time from the moment the nonce is sent (e.g., by using a counter or a clock).

At block <NUM>, a value may be received by the server <NUM>. The value may be a verification value generated by the other party to the communication (e.g., the computing device <NUM>). In an embodiment, the computing device <NUM> may receive the nonce, and pass it to the dedicated computation module <NUM> to compute a predetermined function F based on the value of the nonce and send the computed value back to the server <NUM> as the verification value. As described above, in some embodiments the function F may be a hash function H or an encryption function E to be performed sequentially a number of times (optionally, the variable N may also be received along with the nonce).

Then at block <NUM>, the time duration T between the nonce being sent and the verification value being received is compared to a predefined time threshold Tth. In embodiments in which the predetermined function F starts computation only after receiving the last bit of the nonce V<NUM> and all the bits constituting the output of the function are obtained simultaneously, the time duration T between sending the nonce and receiving the verification value may be measured as the time between sending the last bit of the nonce and receiving the first bit of the verification value.

The time threshold Tth may be selected as a sum of reasonably expected times necessary for (i) transmitting the nonce from the server <NUM> to the computing device <NUM>, (ii) calculating the value of the function F by the terminal <NUM>, and (iii) transmitting the calculated value back to the device <NUM>. In some embodiments (for example, if server <NUM> and device <NUM> are physically close and no Internet is involved in communications) such a time threshold Tth can be in microsecond or even in nanosecond range, although it is to be understood that Tth may be any appropriate duration. In one embodiment, for example, it may be known in advance, that using a particular type of communication channel, it may take no more than <NUM> microseconds (µs) for data transmission from one device to another, and <NUM> microseconds for computing the function F using the dedicated computation module <NUM>. In this case, the time threshold Tth may be selected as: <NUM> (from server to client) + <NUM> (for computations) + <NUM> (for transmitting the result back) = <NUM>.

If the amount of time T to receive the verification value is greater than the time threshold Tth, then the server <NUM> may assume that on the other end of the communication link <NUM> is a device incapable of fast computations of function F, and therefore, not equipped with a dedicated computation module <NUM> and, correspondingly, not trusted. In such a case, in some embodiments, the process <NUM> may proceed to the decision block <NUM>, at which the server <NUM> may optionally decide to repeat blocks <NUM> through <NUM> to ensure that the delay is not due to occasional communication problems. In some embodiments, the number of such repetitions may be limited (for example, to <NUM> to <NUM>).

If the time check at block <NUM> passes successfully, then, at block <NUM>, the received value may be compared to an expected value. For example, the server <NUM> may compare the received verification value to a value of the predetermined function F calculated by the server <NUM> itself. Such verification may be done by either a module (not shown) similar to dedicated computation module <NUM>, or using a general-purpose CPU or other means. It should be noted that the server's performance of the predetermined function F in order to verify the verification value received from the device <NUM> is not time sensitive. In other words, it is not necessary that the server <NUM> performs the predetermined function F as fast as the device <NUM> and, therefore, the server <NUM> may perform the predetermined function F on a general purpose computer or other computation device (i.e., one that is slower than the dedicated computation module <NUM>) if desired. In some embodiments, it may make sense to perform computations of the function F on a GPU (not shown) within the server <NUM>. While each single computation on the GPU may be slower than that on the computation module <NUM>, the GPU may have a large number of cores (for example, <NUM> cores), which will allow the server <NUM> to perform attestation of a significant number of devices <NUM> simultaneously.

Alternatively, the comparison at block <NUM> may be performed by applying the inverse of the function F to the received value. In other words, the server <NUM> may perform the inverse of the function F on the received value and determine whether the final output of the inverse of the function F corresponds to the value V<NUM>. In such an embodiment, a one-to-one function may be used as the function F.

In embodiments in which the dedicated computational module <NUM> is stateful, in addition to the verification value, the device <NUM> may also send to the server <NUM> an additional parameter or data representing the final or intermediate state of the dedicated computing module <NUM>. For example, if the function F (or its last step, if the function F is calculated sequentially) comprises a symmetric encryption function that is a stream cipher, a final or intermediate state of this stream cipher may also be sent by the device <NUM> to the server <NUM>. The server <NUM> may use this additional data to enable or to improve the comparison at block <NUM>. For example, the parameter representing the state of the computation module <NUM> may be an additional input when calculating the inverse of the function F. However, there may be other ways in which this additional parameter may be used to improve the comparison at block <NUM>.

If both checks at blocks <NUM> and <NUM> pass, at block <NUM>, the process <NUM> may determine that the attestation has passed. If either the time check at block <NUM> or the value check at block <NUM> fails, the process <NUM> may determine at block <NUM> that the attestation has failed. For example, if the time check at block <NUM> or the value check at block <NUM> fails, the server <NUM> may determine that the computing device <NUM> may be a computing device that has no dedicated computation module <NUM> and, thus, is not a trusted device.

Successful passage of the attestation may be interpreted as "there is an attested device on the other side of the communication channel established in block <NUM>". In embodiments where the communication is over the Internet (or otherwise unprotected), it may be beneficial to have the communication channel(s) to be SSL/TLS channel(s).

In some embodiments, an apparatus (e.g., the server <NUM> and computing device <NUM>) according to an exemplary embodiment of the present disclosure may have secure zones to handle secure communications. Examples of such apparatuses may include Trusted Platform Module (TPM) Security Devices, and electronic devices with a secure zone to handle secure communication, such as, encryption and decryption tasks. An exemplary electronic device with such a secure zone is described in <CIT>. In some cases, the dedicated computation module <NUM> may be implemented as a part of a secure zone.

<FIG> illustrates another exemplary process <NUM> according to the present disclosure. The process <NUM> may be a modified version of the process <NUM> where the communication link <NUM> may provide different transmission times depending on a number of factors, for example, the distance between the server <NUM> and computing device <NUM>, current network conditions, etc. Uncertain network conditions may occur, for example, when the communication link <NUM> is the Internet. In such cases, the function F may be selected such that the computation time using the dedicated computation module <NUM> may depend on parameters for the function F.

The process <NUM> may start at block <NUM>, at which the computing device <NUM> and the server <NUM> may establish a communication channel (e.g., over the communication link <NUM>) to communicate data. Such communication channel may be similar to the communication channel established in block <NUM> described above with respect to <FIG>.

Then the process <NUM> may proceed to block <NUM>, at which a round-trip time (RTT) for the communication link <NUM> may be determined. The RTT may be obtained, for example, by transmitting a request from the server <NUM> to the computing device <NUM> and receiving a reply to the request from the computing device <NUM>. Other ways of determining the RTT, depending on the nature of the communication link <NUM>, are also possible. For example, if the communication link <NUM> is the Internet, standard Internet Control Message Protocol (ICMP) echo request/echo response may be used for this purpose.

At block <NUM>, the server <NUM> may select parameters for the function F based on the determined RTT. For example, assuming the amount of time necessary for computation using the dedicated computation module <NUM> may be represented as Tdedicated, the minimum amount of time necessary for such computation using a non-dedicated computation module may be represented as Tnon-dedicated, then the computation parameters (e.g., the number of iterations N) for the function F may be selected such that Tdedicated + RTT < Tnon-dedicated may be achieved.

For example, assuming that Tdedicated = N * Td (where N is the number of rounds, and Td is a constant representing the time necessary for performing a single round of computations), and Tnon-dedicated ≥ Tdedicated * <NUM> (i.e., all non-dedicated devices are at least twice slower than the dedicated device), then to satisfy the condition above, N may be greater than RTT / Td. With such a value of N, Tnon-dedicated - (Tdedicated + RTT) > Tdedicated * <NUM> - (Tdedicated + RTT) = Tdedicated - RTT = N * Td - RTT > RTT / Td * Td - RTT = <NUM>, and therefore, Tnon-dedicated > (Tdedicated + RTT) as desired.

It should be noted that, if an emulator (without the dedicated computing module <NUM>) is running at the computing device <NUM>, the overall response time (e.g., the data transmission time plus the computation time) from the emulator should be greater than the time necessary for computations using a dedicated computation module <NUM> plus the time necessary for data transmission, and thus, such an emulator will be recognized as non-trusted. In some situations, however, a malicious (or non-trusted) client device may try to trick the server <NUM> at block <NUM> such that the server <NUM> may determine an inaccurate RTT. For example, a malicious device at the place of the computing device <NUM> may intentionally delay the echo, such that the server <NUM> may determine an RTT greater than the actual time needed. In this case, the process <NUM> may still guarantee that if block <NUM> is reached, the attestation is successful and a device with a dedicated computation module <NUM> is on the other side of the communication channel. An attacker manipulating the RTT can achieve at most either failing attestation of a valid device, or increasing the amount of work performed by both server <NUM> and dedicated communication module <NUM> for attestation purposes.

For example, if according to the determination done at block <NUM>, the RTT is <NUM> second, and assuming the fastest method of computing the function F using a non-dedicated computation module requires more than twice the amount of the time required by the dedicated computation module <NUM>, then to assure that Tdedicated + RTT < Tnon-dedicated the computation parameters may be selected such that the necessary time to compute the function F using dedicated computation module <NUM> would be at least <NUM> second. If a (correct) result is returned in <NUM> seconds (e.g., <NUM> second (for data transmission) + <NUM> second (for computations)), it may be assumed that such computations could not have been done using a non-dedicated computation module (which requires at least twice the amount of time to perform the function F compared to the dedicated computation module). Accordingly, the computation within the threshold time Tth may only have been performed by a client device <NUM> with a dedicated computation module <NUM> and, therefore, may be considered as properly attested.

If a malicious device would delay the echo such that, at block <NUM>, the server <NUM> may (incorrectly) estimate the RTT as, for example, <NUM> seconds, and again assuming the fastest method of computing the function F using a non-dedicated computation module requires more than twice the amount of time required by the dedicated computation module <NUM>, then to assure that Tdedicated + RTT < Tnon-dedicated the computation parameters may be selected such that computations using dedicated computation module <NUM> would be faster than that using non-dedicated computation module by at least <NUM> seconds. Therefore, the computation parameter may be selected such that computations using dedicated computation module <NUM> may need <NUM> seconds and using a non-dedicated computation module may need more than <NUM> seconds. Accordingly, the server <NUM> may be configured to expect to receive the result in <NUM> seconds (e.g., <NUM> seconds (for data transmission) + <NUM> seconds (for data computations)), while the emulator using a non- dedicated computation module can only be able to provide results at best in <NUM> seconds: <NUM> second (for data transmission) + (more than) <NUM> seconds (for data computations), and thus, will still be detected as a non-trusted device.

Then the process <NUM> may proceed to block <NUM>, at which the process <NUM> (e.g., blocks <NUM> through <NUM> of the process <NUM> described with respect to <FIG>) may be performed with the computation parameters generated at block <NUM>.

It some embodiments, the server <NUM> may preliminarily estimate the RTT based on pre-existing estimates of RTTs between the two devices (for instance, on RTTs observed during establishing a TCP connection with the client device <NUM>); select parameters for the function F based on this preliminary estimation; and proceed to block <NUM>, at which the process <NUM> (e.g., blocks <NUM> through <NUM> of the process <NUM> described with respect to <FIG>) may be performed with the selected parameters. If, as a result, the client device <NUM> is successfully attested, no further steps may be necessary. Otherwise, if the process <NUM> fails, this may be a result of incorrectly determined RTT and the server <NUM> may start over from the block <NUM> as described above.

In other embodiments, the amount of work (e.g., the value of N) may not be explicitly specified in the request sent to the client device <NUM>. Instead, the client device <NUM> may itself select the amount of work to be performed, and send the amount of work performed (e.g., the value of N) together with the result of computation to the server <NUM>. The amount of work may be selected so that it would be evident that only a client device <NUM> with a dedicated computation module <NUM> may perform this work during the time actually spent for the computation and sending the result. For example, the client device <NUM> may base this selection on the RTTs observed during establishing a TCP connection with the server <NUM>. When the server <NUM> receives the result of computation together with an indication of the amount of work (e.g., the value of N), it may check whether only a client device <NUM> with a dedicated computation module <NUM> may perform this work during the time since the request has been sent. If this check is passed successfully, the server <NUM> may determine that the attestation has been passed successfully. If the check fails, the server <NUM> may additionally try to perform one or more of the processes described above.

<FIG> is a flow diagram illustrating an exemplary process <NUM> for a communication partner (e.g., the computing device <NUM>) to be attested according to the present disclosure. At block <NUM>, a message may be received by the communication partner, for example, by the computing device <NUM> from the server <NUM>. The message may include computation parameters, for example, an initial value (e.g., to be hashed or encrypted based on a predetermined algorithm), and optionally a number N for the number of repetitive calculations to be performed. In addition, in some embodiments, if the calculation to be performed is symmetric encryption, a symmetric encryption key may also be received. Further, in some embodiments, other parameters (depending on the nature of the function F) may also be included in the message.

Then the process <NUM> may proceed to block <NUM>, at which the computation parameters enclosed in the message may be forwarded to a dedicated computation module. The dedicated computation module (e.g., the dedicated computation module <NUM>) may have a fast computation speed, and as described above, the computation parameters may be selected such that the computation time for any non-dedicated computation module will be longer than (or at least as much as) the total amount of the computation time using the dedicated computation module and the time for back and forth data transmission.

At block <NUM>, a predetermined computation may be performed using the dedicated computation module. As described above, the predetermined computation may be, for example, a predetermined hash function H, a symmetric encryption function E, or an asymmetric encryption function A, or a predetermined number of iterations of the hash function H, symmetric encryption function E, or the asymmetric encryption function A. As also described above, if the function F is computed sequentially, it is not required that the same function or algorithm be used at each step of the sequence. Rather, the various functions or algorithms used at each step of the sequential function F may be combined in any manner or order.

At block <NUM>, the computation result of the predetermined computation function may be sent back to the server. For example, the predetermined computation may be performed by the dedicated computation module <NUM> and the result may be sent back to the server <NUM> for verification. In embodiments in which the dedicated computational module <NUM> is stateful, in addition to the verification value, the device <NUM> may also send to the server <NUM> an additional parameter or data representing the final or an intermediate state of the dedicated computing module <NUM>.

It should be noted that in certain embodiments, the computation parameters sent from the sever may indicate which predetermined function should be used. That is, in these embodiments, the server and computing device may have a group of predetermined functions to choose from (e.g., hash functions F1, F2, F3, etc., encryption functions E1, E2, E3, etc.) and the computation parameters generated at blocks <NUM> and <NUM> may include a parameter to select one specific function for computation. In one non-limiting embodiment, different functions of the group may require different amounts of time for computation and thus, the parameter to select one specific function for computation may be one of the parameters determined at block <NUM>.

In some embodiments, a variation of the processes described above may be used. In such embodiments, a client device <NUM> may send to the server <NUM> not only the final result of computation of the function F but also some intermediate results. For example, in the case of a sequential computation, each Kth intermediate result may be sent (e.g., if N = <NUM> for <NUM> rounds of computations to be performed, the intermediate results after the <NUM>th, <NUM>th, and <NUM>th round may additionally be sent to the server <NUM>). K may be, for example, a predefined value, or may be a value sent from server <NUM> to the device <NUM>. Such intermediate results may be used by the server <NUM> to perform certain computations for the verification of the intermediate results received. For example, in the above example, the server <NUM> may do the first <NUM> rounds with the initial value to check that the intermediate result corresponding to the <NUM>th round received from the client device <NUM> is correct. The server <NUM> may do another <NUM> rounds with the intermediate result of the <NUM>th round received from the client device <NUM> to check that the next intermediate result received from the client device <NUM> corresponding to the <NUM>th round is correct; and so on. If any of such checks fails, the server <NUM> may determine that the whole process has failed; and, if each of such checks are successful, the whole process is passed. In some embodiments, the server <NUM> may perform checks on the results (four in the above example for <NUM>th, <NUM>th, <NUM>th and final) in parallel, which may correspondingly reduce overall time necessary for the whole check. For example, this technique may be used to reduce the overall time required for the whole check on a server that has highly parallelized computational engine(s), such as GPU(s).

In some embodiments, the attestation processes <NUM> or <NUM> may be combined with other ways of device attestation (either known in the art or developed in the future). For example, in one embodiment, for a certain device, both traditional device attestation (based on the private key embedded into the device), and the attestation processes <NUM> or <NUM> may be performed. In some embodiments, both traditional device attestation and attestation process <NUM> or <NUM> may be performed over the same SSL/TLS communication channel. This may provide significant improvement over traditional attestation methods, increasing the complexity of attacks required to circumvent attestation. As described above, to circumvent traditional attestation, an attacker only needs to extract the private key of the device, and then use any kind of software emulator. In contrast, if both the traditional attestation and attestation processes <NUM> or <NUM> are performed, to circumvent attestation, an attacker may need not only to extract the device private key, but also to produce a device able of performing computations fast enough. Producing such a device, however, may be very expensive and/or very difficult.

In some embodiments, as described above, an attestation process according to the present disclosure may use connection-based communication. In some other embodiments, the attestation process described above may also be applied to message-based (connectionless) communication.

While specific embodiments and applications of the present invention have been illustrated and described, it is to be understood that the invention is not limited to the precise configuration and components disclosed herein. The terms, descriptions and figures used herein are set forth by way of illustration only and are not meant as limitations. Various modifications, changes, and variations which will be apparent to those skilled in the art may be made in the arrangement, operation, and details of the apparatuses, methods and systems of the present invention disclosed herein without departing from the scope of the invention. By way of non-limiting example, it will be understood that the block diagrams included herein are intended to show a selected subset of the components of each apparatus and system, and each pictured apparatus and system may include other components which are not shown on the drawings. Additionally, those with ordinary skill in the art will recognize that certain steps and functionalities described herein may be omitted or re-ordered without detracting from the scope or performance of the embodiments described herein.

To illustrate this interchangeability of hardware and software, various illustrative components, blocks, modules, circuits, and steps have been described above generally in terms of their functionality. The described functionality can be implemented in varying ways for each particular application -- such as by using any combination of microprocessors, microcontrollers, field programmable gate arrays (FPGAs), application specific integrated circuits (ASICs), and/or System on a Chip (Soc) -- but such implementation decisions should not be interpreted as causing a departure from the scope of the present invention.

A software module may reside in RAM memory, flash memory, ROM memory, EPROM memory, EEPROM memory, registers, hard disk, a removable disk, a CD-ROM, a DVD or any other form of storage medium known in the art.

Claim 1:
A computing device (<NUM>) for attesting a communication partner (<NUM>), comprising:
a communication port; and
a processor configured to:
determine a round-trip time for communication between the computing device (<NUM>) and the communication partner (<NUM>);
obtain a nonce;
based on the round-trip time, select at least one computation parameter for a predefined function that outputs a verification value;
determine a time threshold based on the round-trip time and the predefined function;
generate an attestation request including the nonce and the at least one computation parameter;
send the attestation request to the communication partner (<NUM>) via the communication port;
receive a verification value from the communication partner (<NUM>), wherein the verification value is generated on the communication partner (<NUM>) using the predefined function after the communication partner (<NUM>) receives the attestation request;
determine whether the verification value is received within time threshold;
determine whether the verification value is equal to an expected value; and
determine that the communication partner (<NUM>) is a trusted device if the received value is received within the time threshold and the received value is equal to the expected value.