Device authentication using device environment information

A device authentication server authenticates a remotely located device using a detailed history of movement of the device. Such movement history is represented by data representing a history of the external state of the device within a physical environment, examples of which include accelerometer logs, orientation logs, and magnetic field logs. To authentication of the device, the device authentication server sends a device key challenge to the device. The device key challenge specifies a randomized selection of device attribute parts to be collected from the device and the manner in which the device attribute parts are to be combined to form a device key. The device key is data that identifies and authenticates the device and includes a device identifier and device environmental data for comparison to reference device environmental data.

BACKGROUND OF THE INVENTION

1. Field of the Invention

The present invention relates generally to network-based computer security and, more particularly, methods of and systems for authenticating a device for computer network security.

2. Description of the Related Art

Device identification through device keys, i.e., though a collection of hardware and system configuration attributes, has proven to be invaluable in recent years to such technologies as security and digital rights management. In security, authentication of a person can be restricted to a limited number of previously authorized devices that are recognized by their device keys. In digital rights management, use of copyrighted or otherwise proprietary subject matter can be similarly restricted to a limited number of previously authorized devices that are recognized by their device keys.

Device keys, sometimes referred to as digital fingerprints, should be globally unique and difficult to spoof. Accordingly, IP and MAC addresses make insecure identifiers. In addition, some operating systems limit access to device configuration details, making derivation of a globally unique identifiers of a large population of similar devices particularly challenging.

What is needed is a way to identify and authenticate a device using information of the device that is highly likely to be unique and is accessible to user space applications.

SUMMARY OF THE INVENTION

In accordance with the present invention, a device authentication server authenticates a remotely located device using a detailed history of movement of the device. Such movement history is represented by data representing a history of the external state of the device within a physical environment, examples of which include accelerometer logs, orientation logs, and magnetic field logs.

For example, acceleration of the device through space represents rates of change of velocity of the device through space, which in turn is a measure of rates of change of the position of the device in space. Position, velocity, and acceleration of the device in and through space are external states of the device as “external state” is used herein. Orientation of the device is a measure of the angular deviation of the device the device from perfectly flat (display screen parallel to the surface of the earth) with the top pointed toward magnetic North. Such orientation is an external state of the device. In addition, the external state of the device includes the earth's magnetic field at the physical location of the device measured across three dimensions of device102: x-, y-, and z-axes.

All of these external states of the device are direct or indirect results of external forces being applied to the device, such as being physically carried by a person, being transported in a vehicle, or being acted upon by gravity and a physical collision with an immovable object at the end of a fall, for example. For example, physically carrying the device causes (i) acceleration of device as the device is accelerated to move through space and eventually decelerated to stop, (ii) changes in orientation of the device unless extreme care is taken to avoid even minute changes in the orientation of the device (entirely impractical if carried by a person), and (iii) changes in the earth's magnetic field across the three axes of the device as the physical location and orientation of the device changes.

Data representing these external states of the device is recorded in various logs, including an accelerometer log, an orientation log, and a magnetic field log, for example. These logs represent a history of external states of the device as the device has moved through physical space. The manner in which the device moves through physical space is even more unique than the user of the device herself since each movement of the device is likely to be unique, even if the same user moves the device attempts to move the device exactly the same. Thus, the history of external states of the device is highly likely to be unique among very large populations of devices.

For subsequent authentication of the device, the device provides the device authentication server with a history of external states, sometimes reference to as device environmental data, of the device to store and use subsequently as reference device environmental data.

In subsequent authentication of the device, the device authentication server sends a device key challenge to the device. The device key challenge specifies a randomized selection of device attribute parts to be collected from the device and the manner in which the device attribute parts are to be combined to form a device key. The device key is data that identifies and authenticates the device and includes a device identifier and device environmental data.

The device authentication server authenticates the device when the device identifier of the device key identifies the device and the device environmental data is consistent with the reference device environmental data.

DETAILED DESCRIPTION

In accordance with the present invention, a device authentication server108(FIG. 1) authenticates a computing device102using a detailed history of movement of device102. Such movement history is represented by data representing a history of the external state of device102within a physical environment, examples of which include accelerometer logs, orientation logs, and magnetic field logs.

As used herein, an external state is independent of any state within a device but is limited to aspects of the physical environment that is external to device102. For example, acceleration of device102through space represents rates of change of velocity of device102through space, which in turn is a measure of rates of change of the position of device102in space. Position, velocity, and acceleration of device102in and through space are external states of device102as “external state” is used herein. Orientation of device102is a measure of the angular deviation of device102from perfectly flat (display screen parallel to the surface of the earth) with the top pointed toward magnetic North. Such orientation is an external state of device102. In addition, the external state of device102includes the earth's magnetic field at the physical location of device102measured across three dimensions of device102: x-, y-, and z-axes. All of these external states of device102are direct or indirect results of external forces being applied to device102, such as being physically carried by a person, being transported in a vehicle, or being acted upon by gravity and a physical collision with an immovable object at the end of a fall, for example. For example, physically carrying device102causes (i) acceleration of device as device102is accelerated to move through space and eventually decelerated to stop, (ii) changes in orientation of device102unless extreme care is taken to avoid even minute changes in the orientation of device102(entirely impractical if carried by a person), and (iii) changes in the earth's magnetic field across the three axes of device102as the physical location and orientation of device102changes.

In this illustrative embodiment, device102is a mobile device that includes accelerometers1114(FIG. 11), orientation sensors1116, and magnetic field sensors1118. Acceleration measured by accelerometers1114is recorded in an accelerometer log1150. Orientation measured by orientation sensors1116is recorded in an orientation log1152. Magnetic fields measured by magnetic field sensors1118are recorded in a magnetic field log1154.

Accelerometers1214, orientation sensors1216, and magnetic field sensors1218can measure their respective environmental states at rates of 100 MHz or more. Accordingly, a large amount of data can be gathered relatively quickly. In addition, the manner in which device102moves through its environment is even more unique than the user of device102herself since each movement of device102is likely to be unique, even if the same user moves device102attempts to move device102exactly the same. Thus, the environmental data stored in accelerometer log1150, orientation log1152, and magnetic field log1154is highly likely to be unique among very large populations of devices.

Device authentication system100(FIG. 1) includes device102, a server106, and device authentication server108that are connected to one another through a wide area computer network104, which is the Internet in this illustrative embodiment. Device102can be any of a number of types of networked computing devices, including smart phones, tablets, netbook computers, laptop computers, and desktop computers. Server106is a server that provides services to remotely located devices such as device102but that is configured to require authentication of device102prior to providing those services. Device authentication server108is a server that authenticates devices, sometimes on behalf of other computers such as server106.

Device attributes are described briefly to facilitate understanding and appreciation of the present invention. In this illustrative embodiment, logged environmental data of device102is combined with other attributes of device102to form a digital fingerprint of device102. Such other attributes include hardware and system configuration attributes of device102that make up an internal state of device102. Known device record500(FIG. 5) includes device attributes504, both of which are described in greater detail below. Each device attribute504includes an identifier506and a value508. Other than logged environmental data, examples of device attributes of device102include a serial number of a storage device within device102and detailed version information regarding an operating system executing within device102. In the example of a serial number of a storage device, identifier506specifies the serial number of a given storage device (such as “C:” or “/dev/sda1”) as the particular information to be stored as value508, and value508stores the serial number of the given storage device of device102.

For subsequent authentication of device102, registration in the manner illustrated in transaction flow diagram200(FIG. 2) retrieves logged environmental data from device102.

In step202, device102sends a request for registration to device authentication server108. The request can be in the form of a URL specified by the user of device102using a web browser1120(FIG. 11) executing in device102and conventional user interface techniques involving physical manipulation of user input devices1108. Web browser1120and user input devices1108and other components of device102are described in greater detail below.

In step204(FIG. 2), device authentication server108sends a request to device102for device attributes of device102.

The request sent to device102includes content that causes web browser1120(FIG. 11) of device102to gather attribute data representing hardware and other configuration attributes of device102. In one embodiment, a web browser plug-in1122is installed in device102and, invoked by web browser1120, processes the content of the web page to gather the attribute data in step206. In other embodiments, the attribute data can be gathered by other forms of logic of device102, such as DDK generator1140installed in device102. The various elements of device102and their interaction are described more completely below.

The content that causes web browser1120(FIG. 11) of device102to gather attribute data representing hardware and other configuration attributes of device102includes extraction logic510(FIG. 5) for each of the attributes web browser1120(FIG. 11) is to gather. In an alternative embodiment, DDK generator1140already includes extraction logic for all attributes and device102receives data identifying the particular attributes requested by device authentication server108. Extraction logic510(FIG. 5) defines the manner in which a client device is to extract data to be stored as value508of device attribute504.

Step206for gathering attribute data regarding logged environmental data is shown in greater detail as logic flow diagram206(FIG. 7). In step702, device102determines start and end times for logged environmental data to be collected.

Each of accelerometer log1150(FIG. 11), orientation log1152, and magnetic field log1154are generally of the form of environmental log400(FIG. 4). Environmental log400includes a number of environmental records402, each representing a measured environmental state of device102. X-axis404, y-axis406, and z-axis408represent the measured environmental state of device102along the x-axis, y-axis, and z-axis, respectively, of device102. In the case of accelerometer log1150, x-axis404represents measured acceleration of device102along the horizontal dimension of device102, y-axis406represents measured acceleration of device102along the vertical dimension of device102, and z-axis408represents measured acceleration of device102along a line perpendicular to the display of device102.

Time stamp410specifies the time at which the measurements of environmental record402were captured. The start and end times determined by device102in step702(FIG. 7) specify which of environmental records402(FIG. 4) are to be collected for each of accelerometer log1150(FIG. 11), orientation log1152, and magnetic field log1154. In one embodiment, device102determines that the start time is the very first available environmental record402and that the end time is the current time, retrieving the entirety of all logs. In other embodiments, device102can determine that the start and end times represent a more limited amount of time, such as the first month of logged environmental data available or the most recent week as examples. In some embodiments, logged environmental data might not be available. In such cases, device102creates accelerometer log1150(FIG. 11), orientation log1152, and magnetic field log1154by monitoring accelerometers1114, orientation sensors1116, and magnetic field sensors1118, respectively, for a period of time.

In step704(FIG. 7), device102extracts the logged environmental data for the interval of time determined in step702.

In step706, device102forms a device identifier from the extracted logged environmental data. In this illustrative embodiment, device102forms the device identifier from the extracted logged environmental data in combination with other device attribute data. The device identifier can be a hash of all, or selected parts, of collected device attributed data, for example. After step706, processing according to logic flow diagram206, and therefore step206(FIG. 2), completes.

In this illustrative embodiment, device102—in particular, web browser plug-in1122(FIG. 11) or DDK generator1140—encrypts the attribute data using a public key of device authentication server108and public key infrastructure (PKI), thereby encrypting the attribute data such that it can only be decrypted by device authentication server108.

In step208(FIG. 2), device102sends the attribute data that was gathered in step206to device authentication server108.

In step210, device authentication logic1020(FIG. 10) of device authentication server108creates a device registration record for device102from the received attribute data. Device authentication server108creates a device registration record in the form of known device record500(FIG. 5) for device102by creating a globally unique identifier for device102, or using the identifier formed by device102in step806(FIG. 8), as device identifier502(FIG. 5) and storing the values of the respective attributes, including the logged environmental data, received in step208(FIG. 2) as value508(FIG. 5) in respective device attributes504. Known device record500is described more completely below in greater detail.

In step212(FIG. 2), device authentication server108sends a report of successful registration to device102, providing device identifier502(FIG. 5) of device102for subsequent identification, particularly if it differs from the one generated by device102. After step212(FIG. 2), processing according to transaction flow diagram200completes and device102is registered for subsequent authentication with device authentication server108.

Known device record500(FIG. 5) is a registration record and, in this illustrative example, represents registration of device102. Known device record500includes a device identifier502and a number of device attributes504which are described briefly above. Each device attribute504includes an identifier506specifying a particular type of information and a value508representing the particular value of that type of information from device102. For example, if identifier506specifies a serial number of a given storage device, value514stores the serial number of that storage device within device102. Similarly, if identifier506specifies an accelerometer log, an orientation log, or a magnetic field log of a given storage device, value508stores data representing represents the proper environmental log.

In this illustrative embodiment, value508stores the appropriate log data in the form of environmental log400. In alternative embodiments, value508can store an abstraction of the log data. For example, value508can store a hash of the log data. Alternatively, value508can store data representing the total distance device102has moved using accelerometer log data, the cumulative angle of rotation of device102using orientation log data, and the cumulative change in magnetic field of device102using the magnetic field data.

Device attribute504(FIG. 5) also includes extraction logic510, comparison logic512, alert logic514, and adjustment logic516. The particular device attribute represented by device attribute504is sometimes referred to as “the subject device attribute” in the context ofFIG. 5.

Extraction logic510specifies the manner in which the subject device attribute is extracted by device102. Logic flow diagram206(FIG. 7) is an example of extraction logic510for environmental log data.

Comparison logic512specifies the manner in which the subject device attribute is compared to a corresponding device attribute to determine whether device attributes match one another. For example, if environmental log data is gathered with a specific time range, the comparison can be equivalence of the environmental log data received for authentication with that stored in value508for the specific time range. If the environmental log data is gathered in its entirety and represented as a cumulative change in state, the environmental log data received for authentication should be greater that stored in value508by an amount roughly predicted by the rate of change in the state over time.

Alert logic514can specify alerts of device matches or mismatches or other events. Examples of alert logic514include e-mail, SMS messages, and such to the owner of device102and/or to a system administrator responsible for proper functioning of device102.

Adjustment logic516specifies the manner in which the subject device attribute is to be adjusted after authentication. For example, if the environmental log data received for authentication includes environmental log data that is not already stored in value508, adjustment logic516can cause value508to be updated to include the additional environmental log data. Similarly, if the environmental log data received for authentication is a cumulative representation of the environmental log data, adjustment logic516can cause value508to be updated to include the newly received cumulative representation.

Device attribute504is shown to include the elements previously described for ease of description and illustration. However, it should be appreciated that a device attribute504for a given device can include only identifier506and value508, while a separate device attribute specification can include extraction logic510, comparison logic512, alert logic514, and adjustment logic516. In addition, all or part of extraction logic510, comparison logic512, alert logic514, and adjustment logic516can be common to attributes of a given type and can therefore be defined for the given type.

Transaction flow diagram300(FIG. 3) illustrates the use of device authentication server108to authenticate device102with server106.

In step302, device102sends a request for a log-in web page to server106by which the user can authenticate herself. The request can be in the form of a URL specified by the user of device102using web browser1120(FIG. 11) and conventional user interface techniques involving physical manipulation of user input devices1108.

In step304(FIG. 3), server106sends the web page that is identified by the request received in step302. In this illustrative example, the web page sent to device102includes content that defines a user interface by which the user of device102can enter her authentication credentials, such as a user name and associated password for example.

In step306, web browser1120(FIG. 11) of device102executes the user interface and the user of device102enters her authentication credentials, e.g., by conventional user interface techniques involving physical manipulation of user input devices1108. While the user is described as authenticating herself in this illustrative example, it should be appreciated that device102can be authenticated without also requiring that the user of device102is authenticated.

In step308(FIG. 3), device102sends the entered authentication credentials to server106. In this illustrative embodiment, device102also sends an identifier if itself along with the authentication credentials. Server106authenticates the authentication credentials in step310, e.g., by comparison to previously registered credentials of known users. If the credentials are not authenticated, processing according to transaction flow diagram300terminates and the user of device102is denied access to services provided by server106. Conversely, if server106determines that the received credentials are authentic, processing according to transaction flow diagram300continues.

In step312(FIG. 3), server106sends a request to device authentication server108for a session key using the device identifier received with the authentication credentials.

In response to the request, device authentication server108generates and cryptographically signs a session key. Session keys and their generation are known and are not described herein. In addition, device authentication server108creates a device key challenge and encrypts the device key challenge using a public key of device102and PKI.

To create the device key challenge, device authentication server108retrieves the known device record500(FIG. 5) representing device102using the received device identifier and comparing it to device identifier502. The device key challenge specifies all or part of one or more of device attribute504to be included in the device key and is described in greater detail below.

In step316(FIG. 3), device authentication server108sends the signed session key and the encrypted device key challenge to server106.

In step318, server106sends a “device authenticating” page to device102along with the device key challenge. The “device authenticating” page includes content that provides a message to the user of device102that authentication of device102is underway and content that causes device102to produce a dynamic device key in the manner specified by the device key challenge.

The device key challenge causes web browser1120(FIG. 11) of device102to generate a device identifier, sometimes referred to herein as a dynamic device key (DDK) for device102, e.g., dynamic device key1142. In one embodiment, a web browser plug-in1122is installed in client device102and, invoked by web browser1120, processes the content of the web page to generate the DDK. In other embodiments, DDK1142of device102can be generated by other forms of logic of device102, such as DDK generator1140, which is a software application installed in device102.

The device key challenge specifies the manner in which DDK1142is to be generated from the attributes of device102represented in device attributes504(FIG. 5). The challenge specifies a randomized sampling of attributes of device102, allowing the resulting DDK1142to change each time device102is authenticated. There are a few advantages to having DDK1142represent different samplings of the attributes of device102. One is that any data captured in a prior authentication of device102cannot be used to spoof authentication of device102using a different device when the challenge has changed. Another is that, since only a small portion of the attributes of device102are used for authentication at any time, the full set of attributes of device102cannot be determined from one, a few, several, or even many authentications of device102.

The device key challenge specifies items of information to be collected from hardware and system configuration attributes of device102and the manner in which those items of information are to be combined to form DDK1142. In this embodiment, the challenge specifies one or more attributes related to logged environmental data of device102, e.g., accelerometer log1150, orientation log1152, and/or magnetic field log1154.

The device key challenge can specify multiple parts of a device attribute to include in the device key. For example, the device key challenge can specify that the total distance device102moved in the month of February and the first quarter of the year (including February twice) is to be derived from accelerometer log data and included in the device key. Similarly, the device key challenge can specify that orientation log data from orientation log1152for five small time intervals randomly selected from the entirety of orientation log1152.

To provide greater security, DDK1142includes data representing the logged environmental data obfuscated using a nonce included in the challenge. While use of randomized parts of the logged environmental data precludes capture of any single DDK to be used in subsequent authentication, use of the nonce thwarts collection of randomized parts of the logged environmental data over time to recreate enough of environmental log400(FIG. 4) to spoof authentication in response to a given challenge.

In step320(FIG. 3), device102gathers logged environmental data for inclusion in the DDK according to the device key challenge. Step320is shown in greater detail as logic flow diagram320(FIG. 8).

In step802, device102determines start and end times for logged environmental data to be collected. The start and end times are specified in the device key challenge and the device key challenge can include multiple start/end time pairs.

In step804(FIG. 8), device102extracts the logged environmental data for the one or more intervals of time determined in step802.

In step806, device102packages the extracted logged environmental data in the manner specified in the device key challenge. As noted above, the device key challenge can specify that the an abstraction of the extracted logged environmental data, such as cumulative change in environmental state over time for example. After step806, processing according to logic flow diagram320, and therefore step320(FIG. 3), completes.

Once DDK1142(FIG. 11) is generated according to the received device key challenge, device102encrypts DDK1142using a public key of device authentication server108and PKI.

In step322(FIG. 3), device102sends the encrypted dynamic device key to server106, and server106sends the encrypted dynamic device key to device authentication server108in step324.

In step326, device authentication logic1020of device authentication server108decrypts and authenticates the received DDK. Step326is shown in greater detail as logic flow diagram326(FIG. 6).

In step602, device authentication logic1020identifies device102. In this illustrative embodiment, the received DDK includes a device identifier corresponding to device identifier502(FIG. 5). Device authentication logic1020identifies device102by locating a known device record500in which device identifier502matches the device identifier of the received DDK.

In test step604(FIG. 6), device authentication logic1020determines whether device102is identified. In particular, device authentication logic1020determines whether a known device record with a device identifier matching the device identifier of the received DDK is successfully found in known device data1030. If so, processing transfers to step606. Otherwise, processing transfers to step614, which is described below.

In step606, device authentication logic1020authenticates the received DDK using the known device record500(FIG. 5) for the identified device, e.g., device102. Device authentication logic1020authenticates by applying the same device key challenge sent in step318(FIG. 3) to the known device record500(FIG. 5) that corresponds to the identified device. In this illustrative embodiment, the device key challenge produces a DDK in which a portion of the DDK generated from non-interactive attributes can be parsed from a portion generated from interactive attributes, such that device102can be authenticated separately from the user of device102.

In test step608(FIG. 6), device authentication logic1020determines whether the received DDK authenticates device102by comparing the resulting DDK of step606to the received DDK. In this illustrative embodiment, device authentication logic1020uses comparison logic512(FIG. 5) for each of the device attributes504included in the device key challenge.

If the received DDK does not authenticate device102, processing transfers to step614and authentication fails or, alternatively, to step314(FIG. 3) in which device authentication logic1020sends another device key challenge to re-attempt authentication. If the received DDK authenticates device102, processing transfers to step610.

In step610, device authentication logic1020determines that device102is successfully authenticated.

In test step612(FIG. 6), device authentication logic1020applies adjustment logic516(FIG. 5) of each of device attributes504uses to generate the received DDK. For example, adjustment logic516can specify that, if the received DDK includes logged environmental data not already included in value508, device authentication logic1020incorporates the new logged environmental data into value508. After step612(FIG. 6), processing according to logic flow diagram326, and therefore step326, completes. As described above, authentication failure at either of test steps604and608transfers processing to step614.

In step614, device authentication logic1020determines that device102is not authentic, i.e., that authentication according to logic flow diagram326fails.

In step616, device authentication logic1020logs the failed authentication and, in step618, applies alert logic514(FIG. 5) to notify various entities of the failed authentication. After step618(FIG. 6), processing according to logic flow diagram326, and therefore step326, completes.

In step328(FIG. 3), device authentication server108sends data representing the result of authentication of device102to server106.

In step330, server106determines whether to continue to interact with device102and in what manner according to the device authentication results received in step328.

Server computer106is shown in greater detail inFIG. 9. Server106includes one or more microprocessors902(collectively referred to as CPU902) that retrieve data and/or instructions from memory904and execute retrieved instructions in a conventional manner. Memory904can include generally any computer-readable medium including, for example, persistent memory such as magnetic and/or optical disks, ROM, and PROM and volatile memory such as RAM.

CPU902and memory904are connected to one another through a conventional interconnect906, which is a bus in this illustrative embodiment and which connects CPU902and memory904to network access circuitry912. Network access circuitry912sends and receives data through computer networks such as wide area network104(FIG. 1).

A number of components of server106are stored in memory904. In particular, web server logic920and web application logic922, including authentication logic924, are all or part of one or more computer processes executing within CPU902from memory904in this illustrative embodiment but can also be implemented using digital logic circuitry.

Web server logic920is a conventional web server. Web application logic922is content that defines one or more pages of a web site and is served by web server logic920to client devices such as device102. Authentication logic924is a part of web application logic922that causes client devices and their users to authenticate themselves in the manner described above.

Device authentication server108is shown in greater detail inFIG. 10. Device authentication server108includes one or more microprocessors1002(collectively referred to as CPU1002), memory1004, a conventional interconnect1006, and network access circuitry1012, which are directly analogous to CPU902(FIG. 9), memory904, conventional interconnect906, and network access circuitry912, respectively.

A number of components of device authentication server108(FIG. 10) are stored in memory1004. In particular, device authentication logic1020is all or part of one or more computer processes executing within CPU1002from memory1004in this illustrative embodiment but can also be implemented using digital logic circuitry. Known device data1030is data stored persistently in memory1004. In this illustrative embodiment, known device data1030is organized as all or part of one or more databases.

Device102is a personal computing device and is shown in greater detail inFIG. 11. Device102includes one or more microprocessors1102(collectively referred to as CPU1102) that retrieve data and/or instructions from memory1104and execute retrieved instructions in a conventional manner. Memory1104can include generally any computer-readable medium including, for example, persistent memory such as magnetic and/or optical disks, ROM, and PROM and volatile memory such as RAM.

CPU1102and memory1104are connected to one another through a conventional interconnect1106, which is a bus in this illustrative embodiment and which connects CPU1102and memory1104to one or more input devices1108, output devices1110, and network access circuitry1112. Input devices1108can include, for example, a keyboard, a keypad, a touch-sensitive screen, a mouse, a microphone, and one or more cameras. Output devices1110can include, for example, a display—such as a liquid crystal display (LCD)—and one or more loudspeakers. Network access circuitry1112sends and receives data through computer networks such as wide area network104(FIG. 1).

Accelerometers1114measure physical acceleration of device102in three dimensions and report measured acceleration through interconnect1106to CPU1102for storage in accelerometer log1150. Accelerometers1114are known and are not described further herein.

Orientation sensors1116measure orientation of device102in three dimensions and report measured orientation through interconnect1106to CPU1102for storage in orientation log1152. Orientation sensors1116are known and are not described further herein.

Magnetic field sensors1118measure the earth's magnetic field around device102along three dimensions and report measured magnetic fields through interconnect1106to CPU1102for storage in magnetic field log1154. Magnetic field sensors1118are known and are not described further herein.

A number of components of device102are stored in memory1104. In particular, web browser1120is all or part of one or more computer processes executing within CPU1102from memory1104in this illustrative embodiment but can also be implemented using digital logic circuitry. As used herein, “logic” refers to (i) logic implemented as computer instructions and/or data within one or more computer processes and/or (ii) logic implemented in electronic circuitry. Web browser plug-ins1122are each all or part of one or more computer processes that cooperate with web browser1120to augment the behavior of web browser1120. The manner in which behavior of a web browser is augmented by web browser plug-ins is conventional and known and is not described herein.

Operating system1130is all or part of one or more computer processes executing within CPU1102from memory1104in this illustrative embodiment but can also be implemented using digital logic circuitry. An operating system (OS) is a set of programs that manage computer hardware resources and provide common services for application software such as web browser1120, web browser plug-ins1122, and DDK generator1140.

DDK generator1140is all or part of one or more computer processes executing within CPU1102from memory1104in this illustrative embodiment but can also be implemented using digital logic circuitry. DDK generator1140facilitates authentication of device102in the manner described above.

Dynamic device key1142, accelerometer log1150, orientation log1152, and magnetic field log1154are each data stored persistently in memory1104and each can be organized as all or part of one or more databases.

The above description is illustrative only and is not limiting. The present invention is defined solely by the claims which follow and their full range of equivalents. It is intended that the following appended claims be interpreted as including all such alterations, modifications, permutations, and substitute equivalents as fall within the true spirit and scope of the present invention.