Scheme for blocking the use of lost or stolen network-connectable computer systems6925562Abstract Scheme for switching a computer system (21), which is connectable via a communication interface and a network (22) to a server module (23), into a special mode of operation. The computer system (21) comprises a software component (26) for sending an identifier (w) assigned to the computer system (21) via the communication interface and the network (22) to the server module (23). In response, the software component (26) receives a token (S), issued by the server module (23), whereby the token (S) comprises a credit (C). In addition, the computer system (21) comprises a trusted hardware component (25) storing the identifier (w) and comprising a credit counter (44) with a credit which is automatically exhaustible step-by-step, and which is updateable with the credit (C) received from the server module (23). The computer system (21) has a trigger unit for switching the computer system (21) into the special mode of operation, e.g. a mode where the computer system (21) is of limited use to a user, if the credit of the credit counter is exhausted. Claims 1. Method for switching a computer system (11; 21; 60), which is connectable via a communication interface (64) and a network (12; 22; 62) to a server module (13; 23; 61), into a special mode of operation, the method comprising the steps: Description TECHNICAL FIELD
It is an advantage of the present scheme that by combining a trusted hardware component and an untrusted software component a tamperproof implementation can be obtained that more secure than known approaches. Any protection scheme that relies purely on software can be more easily tampered. A hybrid computer system with a trusted hardware component and an untrusted software component offers maximum flexibility while keeping the hardware requirements simple. It is a strength of the present scheme that it is resistant to attackers. Furthermore, it guarantees privacy and it is scalable. DESCRIPTION OF THE DRAWINGS The invention is described in detail below with reference to the following schematic drawings. It is to be noted that the Figures are not drawn to scale. FIG. 1 is a schematic block diagram used to describe the basic concept of the present invention. FIG. 2A is a schematic block diagram of a first embodiment, in accordance with the present invention. FIG. 2B is a schematic block diagram of the trusted hardware component of a computer system of the first embodiment. FIG. 2C is a schematic flow chart depicting the steps performed by the server module of the first embodiment. FIG. 3A is a schematic block diagram of another computer system, in accordance with the present invention. FIG. 3B is a schematic flow chart depicting the steps performed by the computer system of FIG. 3A. FIG. 3C is a schematic block diagram depicting the exchange between the computer system of FIG. 3A and a server module. FIG. 4A is a schematic block diagram of another computer system, in accordance with the present invention. FIG. 4B is a schematic block diagram of a server module, in accordance with the present invention. DESCRIPTION OF PREFERRED EMBODIMENTS The present scheme can be used in wireless networks, wire-based networks or fiber-based networks which are deployed in warehouses, on manufacturing floors, in offices, on trading floors, in private homes, in cars and trucks, in airplanes, and outside of buildings, just to mention some examples. Any kind of network, including the Internet and the world wide web (WWW), is meant when herein referring to a network. Simple point-to-point links or point-to-multipoint links are also meant to be covered by the word network. When referring to a computer system, any kind of device is meant that can be attached or hooked up to a network. Examples of computer systems are: laptop computers, workpads, nodepads, personal digital assistants (PDAs), notebook computers and other wearable computers, desktop computers, computer terminals, networked computers, internet terminals and other computing or networking systems like bridges, switches, routers, and set-top boxes, cash registers, bar code scanners, point of sales terminals, kiosk systems, cellular phones, pagers, wrist watches, digital watches, badges, and smart cards. Other contemplated devices include: headsets, Human Interface Device (HID) compliant peripherals, data and voice access points, cameras, printers, fax machines, keyboards, joysticks, HiFi systems, audio (sound) cards, loudspeakers, amplifiers, video cards, kitchen appliances, tools, sensors such as smoke and/or fire detectors, and virtually any other digital device. Other examples of wearable computers that can be used in connection with the present invention are, personal effects being equipped with computer-like hardware, such as a "smart wallet" computer, jewelry, or articles of clothing. In addition to a "smart wallet" computer, there are a number of other variations of the wearable computers. A "belt" computer is such a variation which allows the user to surf, dictate, and edit documents while they are moving around. Yet another example is a child's computer which is comparable to a personal digital assistant for grade-school children. The child's computer might hold assignments, perform calculations, and help kids manage their homework. It can interface with other children's computers to facilitate collaboration, and it can access a teacher's computer to download assignments or feedback. Any wearable or portable device, any office tool or equipment, home tool or equipment, system for use in vehicles, or systems for use in the public (vending machines, ticketing machines, automated teller machines, etc.) might comprise the present invention. For the purpose of the present invention also cars, trucks, and any other vehicle that comprises kind of a computer system are considered to be a computer system in the broadest sense. In other words, the present invention can also be employed to discover and, if desired, track down stolen vehicles. It is furthermore assumed that a computer system, as used in connection with the present invention, has a minimum amount of processing power that enables it to communicate with a network. These computer systems are thus herein referred to as network-attached (or network-attachable) computer systems. The network-attached computer system needs to be able to transmit information to a network and/or receive information from a network. For this purpose it comprises a communication interface (e.g., a transmitter, receiver, and some protocol stack to support and enable the exchange of information via a network). A server module, as employed in connection with the present invention, can be a dedicated server or a module within a server, a computer system connected to a network, or a switch, router, bridge or any other network device which has some processing power that enables it to communicate via a network with a computer system and to perform the steps of the present invention. A farm of computer systems can be employed as server module. This server module can be managed by any appropriate entity and not necessarily the current user of a protected computer system. The server module can for example be operated and managed by an independent authority. The server module needs to be able to transmit information to a network and/or receive information from a network. For this purpose it comprises a network interface (e.g., a transmitter, receiver, and some protocol stack to support and enable the exchange of information via a network). Identifier: A key element of the present invention is an identifier w. Any kind of identifier w can be used to identify the computer system to a server module. Ideally, the identifier w is unique within the network. The identifier w can be set by the manufacturer who makes the computer system or the store where the system is sold, for example. One may for example use a so-called Asset ID (Asset identifier), as provided by the ATMEL MSC0402 chip made by Atmel Corporation. Secure Identifier: The identifier w is encrypted before leaving the computer system's trusted hardware, e.g. for being transmitted via a network to a server module. The encrypted identifier is herein referred to as secure identifier E(w). The word secure is used herein to indicate that the identifier w cannot be changed or acted upon by a non-authorized person or system. One may use a secure identifier E(w) which is optimized so that the transmission across the network is efficient. In addition to the identifier w, the secure identifier E(w) might comprise a time stamp and other information, e.g., an unpredictable random sequence of bits n, or an ever increasing or decreasing number n, or a nonce n. This time stamp or other information is for sake of simplicity herein referred to as additional information n. If the secure identifier carries the identifier w and additional information n, for instance, then this is denoted as E(w,n). In order to generate the secure identifier E(w), the identifier w is encrypted using a cryptographic key k. This step is also referred to as encryption step. The computer system may take the server module's public cryptographic key and use it to encrypt its identifier w before sending it across the network. There are many other ways for the encryption of the identifier w. Instead of a public key encryption approach one may use a shared secret key approach, for example. Cryptographic key: Since the identifier w is encrypted using a cryptographic key k (e.g., the server module's public cryptographic key) prior to its transmission to the server module, the server module-according to the present invention-needs a corresponding cryptographic key (e.g., a secret (private) cryptographic key) in order to be able to decrypt the received secure identifier E(w,n). The cryptographic key k for encryption of the identifier w can be a public cryptographic key and the cryptographic key for decryption of the received secure identifier E(w,n) can be a private cryptographic key as used in connection with known public key cryptography. Preferably, nobody should have access to the cryptographic key k for encryption of the identifier w in combination with the computer system's identifier w. Public key cryptography: A method for creating two keys (also called a key pair) that can be used to encrypt and decrypt messages. One of the two keys, the public key, is widely published, while the other key, the private key is kept secret. If one wants to encrypt a message for a recipient, one uses that recipient's public key; only someone with the private key can decrypt the message. If one wants to digitally sign a message, one uses the private key; anyone with the corresponding public key can then check the signature and verify that only a 'trusted' party could have signed the message. Trusted hardware component: A trusted hardware component is a component (e.g., a chip or a chip set) that meets certain security standards to prevent unauthorized access or modification. In other words, a trusted hardware component is a component that is protected in order to be tamperproof. Network topology: The present scheme can be used in connection with any kind of network which at least allows the computer system to send information to a server module. The network topology is lower-level than the subject of the present invention. Aspects of the network topology are only addressed to the extent necessary, i.e., the present invention is independent of the network topology. Network technology: The present scheme can be used in connection with any kind of network technique, such as Ethernet, Token Ring, ATM, RF, IR, and the like. Transmission of Identifier: An example of a scheme for transmission of the identifier w is now addressed. A computer system can send from time to time, e.g., at random or regular intervals, its secure identifier E(w) to a specific server module which is reachable via a network. The transmission could also be carried out each time the computer system is connected to a network, for example. The address or identity of this server module (server module address) can be kept inside said computer system in form of an address list, for example. The DNS (Domain Name System) information of server modules could for example be hard-coded inside the computer system's hardware. Likewise, it might be provided in a file or in a hard disk partition of the computer system. If no address is provided in the computer system, the address can be learnt dynamically on-the-fly. There are networks where the computer system does not need the server module's address in order to be able to send the secret identifier to it (broadcasting, layer 4 routing, etc.). The present invention is independent of the scheme for transmission of the identifier. What is required is that a computer system, according to the present invention, announces its identity w by sending a secure identifier E(w) to a specific server module. How this is done and how often the transmission is repeated is implementation dependent. Before addressing detailed embodiments of the invention, the underlying scheme is addressed and additional terms are defined. A typical network system 10 is illustrated in FIG. 1. There is a computer system 11 (e.g., a notebook computer) which is connected via a network 12 to a server module 13. For sake of simplicity the network 12 is represented in form of two simple arrows because the structure, type, and size of the actual network is not of relevance. In other words, any kind of network 12 can be used to link the computer system 11 to a server module 13. The computer system 11 either comprise the address of a server module 13 or it is linked to the server module 13 in a fashion that no specific address is required (broadcasting, layer 4 routing, etc.). An identifier w and a cryptographic key k is available at the computer system 11. From time to time, the computer system 11 transmits its secure identifier E(w) to the server module 13. To allow a verification of the computer system 11 by the server module 13, the identifier w is encrypted using the cryptographic key k, as indicated by the expression E(w), before its transmission. This is important because otherwise an unauthorized third party (e.g., an intruder or hacker) could misuse the identifier w of a specific computer system. Such a misuse can be prevented if the identifier w is encrypted using a cryptographic key k. The server module 13 comprises a cryptographic key for decryption (e.g., a secret (private) key) of the secure identifier E(w), or it has access to a list with the cryptographic key for decryption. If the server module 13 receives a secure identifier E(w) it decrypts it to obtain the identifier w. Note that if additional information n is sent together with the identifier as secure identifier E(w,n), then the server module 13 decrypts this secret identifier E(w,n) to obtain the identifier w and the additional information n. The server module 13 either comprises a list 14, e.g. a 'black list', or it has access to such a list where the identifiers of computer systems 11 are listed that are reported lost or stolen. The module 13 now compares the identifier w with the entries in the black list 14 to check whether there is a matching identifier listed. If the computer system's identifier is listed on the black list 14 this means that the computer system 11 which transmitted the secure identifier E(w,n) was lost or stolen. If the computer system's identifier is not listed, then it is assumed that everything is in good order, i.e. the secure identifier E(w,n) was issued by a computer system 11 that was neither reported lost nor stolen. Based on the comparison with entries in the black list 14 the server module 13 now decides, e.g. by taking into consideration certain predefined rules, whether to grant the computer system 11 any credit C, and, if it decides to grant credit C, how much credit C it grants. The server module may keep state information in order to be able to control at a later point in time, e.g. when it receives another request for credit from a particular computer system, whether it has previously granted any credit to this particular computer system and/or how much credit it has granted. Note that the keeping of state information is optional. The credit can be a simple number representing a credit amount, or a token that tells the computer system that it can run for a certain period of time, or a pointer to a table or memory where a credit amount is stored. Other schemes for granting the computer system a credit are conceivable. The server module 13 dynamically controls or changes the computer system's operation by sending the credit information. As shown in FIG. 1, the server module 13 returns the information S(m) to the computer system 11. S(m) denotes a message m and the server module's digital public key signature on the message m. The digital signature on message m is obtained by encrypting a hash of m using a cryptographic key, e.g. the server module's private key. This digital signature is employed to prove that the server module as holder of the cryptographic key is the originator of a message S(m). If the signature is successfully verified then the computer system can trust the server module. A trusted server module is a server that is known to the computer system. For this purpose the computer system may contain a list of server modules, for example. This list may comprise the public keys of the trusted server modules. The message m represents the identifier w and the credit C. If additional information n was transmitted in the secure identifier-as denoted by E(w,n)-then this additional information n is also returned to the computer system 11 in the message m. I.e., in this case, the message m represents the identifier w, the additional information n, and the credit C. This is denoted by S(w,n,C). The computer system 11 receives S(m). It now uses its cryptographic key k to decrypt S(m). Since the computer system 11 knows its own identifier w, it is able to determine whether S(m) was sent by the server module 13 and whether this server module 13 is a 'trusted' server module. If the message S(m) came from a trusted server module, then the computer system can extract/derive the credit C. Depending on the actual implementation, the computer system 11 can now use the credit C to update a credit counter. Such a credit counter can be implemented in different ways: Either (1) it is implemented as a counter which decreases its credit amount over time, or (2) it is implemented as a counter which increases its credit amount over time. In case (1) the credit C may be a positive number, preferably an integer number, that is simply added to the current amount of the credit counter. In case (2), the credit C may be a positive number, preferably an integer number, that is simply subtracted from the current amount of the credit counter. It is also possible to implement the present invention in a manner that the received credit C is used to overwrite the current value held in the credit counter. This is advantageous since it helps to avoid that a computer system accumulates credits over time. Another approach for avoiding accumulation of credit information would be to limit the maximum value the credit counter can take on if the counter decrements the value, or to limit the minimum value the credit counter can take on if the counter increments the value. Likewise, it is also possible to add a time component to an otherwise time-independent credit counter such that after a number of days for example the computer system is blocked no matter what the credit counters value is. The credit counter is incremented or decremented by a unit at each clock tick of the trusted hardware component's internal oscillator, or each time a specific event occurs. The computer interrupts its regular operation (regular mode) if the credit counter reaches a certain value or threshold v. v could be any number, e.g. v=0, or v=1000. If the credit C is a token, then this token may represent a certain credit amount. A token C1 may represent an amount of 100 and a token C2 may represent an amount of 1000, for example. There could be a lookup table in the computer system which returns the actual amount for a token. In another implementation the token may tell the computer system 11 that it is authorized to run for a predefined duration in its regular mode. A token may be good for 24 hours or 1 billion cycles, for example. Instead of a token or a number, the credit C may represent a pointer. This pointer when received by the computer system 11 points to a table or memory where a credit amount is stored. From this the computer system 11 can derive information that tells it for how long it is supposed or authorized to run in a regular mode. All the above outlined alternatives are for sake of simplicity herein referred to as updating the credit counter. If the credit is used up, the computer system switches to a special mode of operation. This special mode of operation depends on the actual implementation. A few examples of special modes are set forth in the below listing:
The computer system may resume regular operation for a short period of time in order for the system to be able to obtain new credit information from the server module. Another, more detailed implementation of the present invention is described in connection with FIGS. 2A-2C. FIG. 2A illustrates a communication system 20 with computer system 21, network 22, and server module 23. In the present implementation the computer system 21 comprises a trusted hardware component 25 and a software component 26 (e.g., a software agent). The trusted (tamperproof) hardware component may comprise the ATMEL MSC0402 chip made by Atmel Corporation. This chip is an 8-bit microcontroller (cryptographic processor) with advanced security features. The chip can both store secret keys in nonvolatile memory, and compute public key functions using those secret keys. Among these functions is generation of signatures, secure storage and transmission of various secret keys. The chip protects against many of the kinds of breaches that hackers might use to gain secret information. Additional details about this chip and its functionality can be found at http://www.atmel.com/atmel/acrobatl/1504s.pdf. FIG. 2B is a schematic diagram of the computer system's hardware and FIG. 2C is a schematic diagram of the server module's hardware. Please note that in these Figures only those elements are illustrated which are needed to describe the present invention and its implementation. The software component 26 is responsible for contacting the trusted server module 23 to obtain a fresh credit C. For this purpose this software component 26 interacts with a transceiver (not shown) and other components of the computer system 21. Before obtaining a fresh credit C, the computer system 21 has to send a challenge E(w,n) to the server module 23. This server module then eventually returns a fresh credit C. After the fresh credit C was received, the software component 26 feeds the credit amount to the trusted hardware component 25. The trusted hardware component 25 allows regular operation of the computer system as long as the credit lasts. After expiration of the credit, the trusted hardware component forces or triggers the computer system 21 to switch to a special mode of operation. The trusted hardware component 25 may have the following set of capabilities/features/characteristics:
The trusted hardware component also should be able to store and run a small program and associated variables. Here, secure storage means that the expense of modifying securely stored information is higher than the benefits gained from a successful modification. The computer system's (unique) identifier w has to be stored by the hardware component 25 in a manner that any attempt to break into the computer system 11 is more expensive or damaging than the benefit gained from this activity. In other words, the hardware component has to be a trusted component. According to the present invention, the software component 26 of the computer system 21 obtains the system's identifier w and additional information n from the hardware component 25. For this purpose the hardware component 25 comprises a building block (not shown) which generates or obtains this additional information n. In the present implementation this building block comprises a random number generator. Such a random number generator can be realized in hardware, software, or a combination of both. Preferably, the random number generator is implemented in a way that it generates unpredictable random numbers n. Each time the computer system 21 sends out a secure identifier E(w,n) to the server module 23 another random number n is used. Whenever the random number n changes also the secure identifier E(w,n) changes. n is employed as additional information to ensure freshness and to prevent replay attacks by somebody who recorded old messages exchanged between the computer system 21 and the server module 23. The trusted hardware component 25 encrypts the identifier w and the random number n using the cryptographic key k to generate a secure identifier E(w,n), referred to as secure identifier. This secure identifier E(w,n) is then provided by the hardware component 25 to the software component 26. The software component 26 sends the secure identifier E(w,n) via a transceiver (not shown) and said network 22 to the server module 23. The secure identifier E(w,n) may be sent just before the current credit of the computer system 21 expires, or after a certain predefined time interval. If the computer system 21 is disconnected from the network 22, e.g., because it is used in an island mode, the secure identifier E(w,n) may be sent out the next time the computer system 21 is connected to the network 22. After the secure identifier E(w,n) was transmitted the computer system 21 now waits for a credit, as indicated in box 15 of FIG. 2B. The server module 23 waits until it receives a secure identifier E(w,n) via the network 22, illustrated as step 30 in FIG. 2C. It then fetches a key and uses this key to decrypt the secure identifier E(w,n) (step 31). This key may be a secret (private) key, for example. By decryption of the secure identifier E(w,n) the server module 23 obtains the identifier w and the random number n in the clear. In step 32 the server module 23 compares the identifier w with the identifier(s) on a list 24. The server module 23 either comprises a list 24 or it has access to a list where the identifiers of computer systems 21 are listed that are reported lost or stolen. In the present implementation example the list 24 is a 'black list'. If the server module 23 finds a matching entry in the black list it assumes that the computer system 21 from which it just has received the secure identifier E(w,n) was either reported stolen or lost. The flow-chart follows path 39. The server module 23 does not grant the computer system 21 any credit (step 34). Likewise, the list 24 may be a list that comprises all computer systems that are NOT reported lost or stolen. Such a list 24 is herein referred to as 'valid list'. If the server module 23 finds a matching entry in the valid list it assumes that the computer system 21 from which it just has received the secure identifier E(w,n) was neither reported stolen nor lost. In other words, it assumes that it is OK to grant the computer system credit. Such a valid list may be advantageous in a setup with only a very limited number of computer systems. In the Internet, for example, the number of entries in a valid list would be too large to handle. Instead of a black list or valid list one can also employ a customized credit list, or any combination of such lists. A customized credit list may contain specific values that should be returned by the server module. This can be used to temporarily override a default credit value, for example. If the server module 23 determined that the computer system 21 is reported stolen or lost (step 33), then it grants no credit C to the computer system 21 (step 34), as mentioned above. There are two ways to implement this. The server module 23 may simply refuse to send a message S(w,n, C) to the computer system 21 in which case the computer system 21 uses up all of its credit C until C reaches a certain value or threshold v (box 27 in FIG. 2B). Likewise, the server module 23 may send a message S(w,n,C) where (1) C represents a negative credit. The computer system 21 receives the negative credit C and updates its credit counter (box 28 in FIG. 2B). This reduces the available credit and the computer system quickly reaches a state where C reaches the value v (box 27 in FIG. 2B). (2) C represents a positive credit. The computer system 21 receives the positive credit C and updates its credit counter (box 28 in FIG. 2B). This reduces the available credit by increasing the credit counter's value and the computer system quickly reaches a state where C reaches the value v (box 27 in FIG. 2B). (3) C equals v (e.g. C=0). The computer system 21 receives C=v and updates its credit counter (box 28 in FIG. 2B) by overwriting its current value. In doing so, the credit counters value immediately reaches v (box 27 in FIG. 2B). Instead of sending a negative credit, the server module 23 may send an invalid credit or a flag. The computer system recognizes that an invalid credit C or a flag was received and switches from its regular mode of operation to a special mode of operation, as indicated by arrow 29 and box 35 in FIG. 2B. Assuming now that the secure identifier E(w,n) came from a computer system 21 that is neither reported lost or stolen, the server module 23 grants a credit C. It can either determine the amount of credit C according to certain rules, or it may simply grant a standard amount, or it may pick a suited credit amount from a lookup table. This is depicted as step 36. The credit C may be large for rarely connected computer systems, or small for computer systems in a tightly controlled building or network. The secure identifier E(w,n) may include a suggested credit value c0, as denoted by E(w,n,c0). By sending this suggested credit value c0 the computer system suggests to the server module to use this special value c0 rather than another credit amount. The credit C may be expressed in absolute time or, preferably, in relative time. The absolute time approach provides for a concise syntax to express rules, such as "work until Oct. 1, 2000". However, the trusted hardware component 25 would have to be able to keep the date, which is a rather complicated and expensive operation since one cannot rely on the clock of the computer system 21 which can be easily manipulated by an adversary. If a relative time scale is used, the trusted hardware component 25 does not need to keep the current date which is a complicated operation. The trusted hardware component 25 does not need to have a notion of date. If a relative time scale is used, then it is sufficient to simply decrement the credit counter at each tick of the trusted hardware component's clock. As mentioned above, the trusted hardware component 25 may comprise a simple credit counter that is either decremented or incremented at each tick of a clock or at the occurrence of special events. In a next step 37 the information w,n, C is encrypted. In the present implementation, the server module 23 generates the binary XOR (⊕ is the binary XOR operator) of w and n to obtain H, where H=w⊕n. The XOR combination of n and w is the most secure type of encryption. It is resistant against infinite computer power attacks if n is a random number. Then, the server module 23 concatenates C and H (C is appended to H), as denoted by H∥C. Finally, H∥C is signed using the server module's secret (private) cryptographic key to obtain the signature of H∥C, which is denoted by sign{H∥C}. The server module 23 then transmits sign {H∥C} via the network 22 to the computer system 21, as indicated in box 38. By convention, sign{H∥C} comprises H∥C and sign{H∥C}. Please note that in FIGS. 2A and 2C the expression S(w,n,C) represents H∥C and sign{H∥C} together. The computer system's trusted hardware component 25 receives H∥C and sign{H∥C}. It verifies the validity of the received message S(w,n,C), as described in the next section. Since the trusted hardware component 25 knows w and n, it is now able to take H and to do an XOR operation with n in order to extract w from H∥C. This operation can be illustrated by: (w⊕n)⊕n→w, where (w⊕n)=H. If H⊕n==w, then the computer system 21 checks sign{H∥C} to determine whether the credit C was granted by the trusted server module 23 (i.e., the computer system 21 checks whether the signature sign{H∥C} is valid. If the signature sign {H∥C} is valid, then it is clear that the credit C was granted by the trusted server module and the trusted hardware component 25 updates the credit counter (see box 28 of FIG. 2B) and the computer system 21 returns to a mode (box 15) where it waits for the next credit information. As illustrated in FIG. 2B, the computer system's trusted hardware component 25 may have a timeout feature where the TIMEOUT value (grace period) is a suitable parameter, e.g. in the order of a few minutes, to allow the computer system's software component 26 to contact the server to obtain fresh credit information. An adversary cannot record and replay previously sent credit information because the hardware component 25 will not accept credit information containing a previously used random number n. Moreover, only a trusted server module can create correctly signed credit information S(w,n,C). Another embodiment of the present invention is described in connection with FIGS. 3A through 3C. FIG. 3A is a schematic block diagram of a computer system's trusted hardware component 40. It comprises a processor 41, a memory 42 (preferably a non-volatile memory), a bus structure 43, a credit counter 44, a random number generator 51, and a clock generator 45. In the present embodiment there is also a dedicated unit 47 which causes the computer system 60 to switch from its regular mode of operation to a special mode of operation if the credit C is exhausted. Instead of providing a dedicated trigger unit 47 for this purpose, one may implement this such that the processor 41, for example, causes the computer system to switch from its regular mode of operation to a special mode of operation. The processor 41 executes a small program 46 that sits in the memory 42. This memory also securely stores the computer system's identifier w and the cryptographic key k. The clock generator 45 generates clock pulses that are independent from the computer system. These clock pulses are fed via line 48 to the credit counter. This credit counter decrements its current value by a unit. The trigger unit 47 detects via the bus 43 when the credit is exhausted. The trusted hardware component 40 interfaces via a port 49 with the computer system's software component 50. Assuming now that the computer system 60 is in its regular mode of operation and that the current credit is about to be exhausted, the computer system's software component 50 queries (newQuery routine) the hardware component 40 for a new challenge E(w,n) (reference number 101 in FIG. 3B). Note that in the present example a nonce n is used as additional information. The hardware component 40 checks whether a nonce n is pending (reference number 200). If the nonce n is not pending (reference number 202), then the hardware component 40 makes a new random nonce n (reference number 203) available to the processor 41. This random number is generated by a random number generator 51. The random number generator can be implemented in hardware, software, or a combination of hardware and software. Preferably, n must be kept secret, because otherwise a hacker who knows n could derive w in the response H∥C. One way to achieve this is to generate n inside the trusted hardware component and to encrypt it together with the identifier w before it leaves the trusted hardware component. The processor 41 then fetches the identifier w and key k from the memory 42 and generates a secure identifier E(w,n) by encryption of the identifier w and nonce n with the key k. This secure identifier E(w,n) is returned to the software component 50 via bus 43 (reference number 300) and the trusted hardware component 40 returns to an idle state (reference number 100). If a nonce n from a previous challenge is still pending, e.g. because no response was received from the server module 61, then no new nonce n is picked. Instead, the trusted hardware component 40 returns the previously used secure identifier E(w,n) to the software component 50. Each time the software component 50 receives a new token sign{H∥C} from the server module 61, it sends this new token sign{H∥C} via port 49 to the trusted hardware component 40 (reference number 102) (newToken routine). The processor 41 checks whether this new token sign{H∥C} is valid (reference number 400). If this token is valid (reference number 401), then the processor 41 causes the credit counter 44 to be updated (reference number 500). If the token is not valid, then the trusted hardware component 40 returns to an idle state (reference numbers 402 and 100). As long as the credit is not exhausted, i.e., if the credit is positive in the present example, the trusted hardware component 40 returns to an idle state (reference numbers 502 and 100). If the credit counter 44 reaches 0 or assumes a negative value (e.g. after an update with a negative credit), then the trigger unit 47 triggers or forces the computer system 60 to switch from the regular mode of operation into a special mode of operation (reference numbers 501 and 700). More details of this embodiment are given in the following sections. As mentioned earlier, after a valid token sign {H∥C} was fed to the trusted hardware component 40 by the software component 50, the computer system 60 remains in its regular mode of operation as long as the credit counter's amount is positive. At a safe margin prior to the expiry of the credit, the software component 50 calls the newQuery routine in the trusted hardware component 40. This routine returns a secure identifier E(w,n) via bus 43 to the software component 50 (reference number 300), where n is a nonce generated by the random number generator 51, w the computer system's identifier, and E denotes public-key encryption with the server's key k. The software component 50 forwards this secure identifier E(w,n) via the computer system's transceiver and the network 62 to which it is attached to a server module 61. Whenever this server module 61 replies with a token sign{H∥C}, this token sign{H∥C} is forwarded by the software component 50 to the trusted hardware component 40 by calling a so-called newToken routine. The server module's reply comprises a signature on H=w⊕n (by convention, a signature also includes the signed message in the clear) concatenated with a new credit C. This reply is referred to as token H∥C. If the computer system which requested a fresh credit is reported lost or stolen, then the value of the credit C is zero, for example. Otherwise, the credit C is a positive integer a whose exact value is rule dependent. This exchange between the computer system 60 and server module 61 is summarized in FIG. 3C. The newToken routine accepts a new token if it bears a valid signature and it checks whether H⊕n=w, where n is the nonce generated by the previous call to the newQuery routine. This check ensures that an adversary cannot replay (replay attack) previously sent tokens. The credit counter 44 is updated with C if the token bears a valid signature. As discussed before, there are different approaches for the updating of a credit counter conceivable. One can update the credit counter by simply add the new credit amount C to the counter's current credit amount. Likewise, one can update the credit counter by overwriting its current amount with the new credit amount received. Here we update the credit counter by overwriting its current amount. If the computer system 60 was stolen, the server module sets the credit to 0 (C=0). The computer system's identifier w is only revealed to the server module 61. Assuming the nonce n is of the same bit-length as w, XOR-ing is secure against any adversary even with infinite computing power. No computationally-bounded adversary nor the software component 50 can retrieve w from E(w∥n), without knowing the trusted server's private key k. An example of the software 46 that the trusted hardware component runs is illustrated in the following. In this example, we assume an oscillator to be available inside the trusted hardware component. The code could be adapted to accommodate other types of events. The code is written in pseudo-code akin to the C language. Note that in the above example, wantedID is the computer system's identifier w and pendingNonce is the nonce n. From line 1 to 6, the code declares a few variables. The rest of the code is structured into three functions, namely clockTick, newQuery, newToken. From line 9 to 16, the clockTick function is defined. It is called at each clock tick, assumed to be at intervals of one second each. This function first decrements the amount of available credit (line 10). If the grace period has not already elapsed (line 12), it increments the grace period counter (line 13). Otherwise, it proceeds to check if the amount of available credit is less or equal to zero (line 14). In case no credit is left, then the computer system is shut down (line 15). From line 19 to 23, the newQuery function is defined. It returns the result of the encryption of the current nonce n and the wantedID w (line 22). In case the software calls newQuery before feeding the server module's response, one re-uses the previous nonce n. Otherwise, one generates a new nonce n (line 21). This is required to prevent a cumulative token attack. Incidentally, this also keeps the memory footprint small because one never has to remember more than one nonce. From line 26 to 38, the newToken function is defined. It is called by the software component to feed the answer of the server module to the trusted hardware component. This function takes a message m and a signature on the message. The code assumes that m is composed of a 128 bit unsigned integer H, followed by a 32 bit integer C. I the present example C-style pointer arithmetic is used to retrieve these values (line 27). On line 28, one checks if the server module's purported answer XOR-ed with the nonce n matches the wantedID w. This check prevents replay attacks. Only if this inexpensive check succeeds does one proceed to verify the signature, a relatively expensive operation (line 29). On line 30, when it is clear that the token is signed and fresh, the pendingNonce value is reset. On line 31, one retrieves the value of C from the message On line 32 one sets the credit counter. A zero value of C (line 34) indicates that the computer system is blacklisted and needs to be brought down (line 35).
|
Same subclass Same class Consider this | ||||||||||