WO2007043015A2

WO2007043015A2 - Improved proximity detection method

Info

Publication number: WO2007043015A2
Application number: PCT/IB2006/053732
Authority: WO
Inventors: Michael Epstein; Marc Vauclair; Ventzislav Nikov
Original assignee: Koninklijke Philips Electronics N.V.
Priority date: 2005-10-13
Filing date: 2006-10-11
Publication date: 2007-04-19
Also published as: WO2007043015A3

Abstract

The invention relates to a method of determining a distance between a first device (200) and a second device (220). In a precomputing phase, both devices (200, 220) compute for a query at a protected query Ma1 and for a response bt a protected response Mb1. In an interactive phase, the first device (200) sends the protected query Ma1 to the second device (220). The second device (220) compares the received protected query Ma1 against the computed protected query Ma1 and sends the protected response Mb1 to the first device (200). The first device (200), compares the received protected response mbt against the computed protected response mbj. The distance is determined based on a measurement of time elapsed between sending the protected query Ma1 to the second device (220) and receiving the protected response Mb1 from the second device (220).

Description

Improved proximity detection method

In recent years, the number of content protection systems available has been growing rapidly. Some of these systems only protect the content against unauthorized copying, while others restrict the user's ability to access the content. These systems are often referred to as Digital Rights Management (DRM) systems. Consumers want to enjoy content without hassle and with as few limitations as possible. They want to network their devices to enable all types of different applications and easily access any type of content. They also want to be able to share/transfer content in their home environment without limitations.

One way of protecting content in the form of digital data is to ensure that content will only be transferred from a transmitting device (source device, e.g. a digital video recorder, DVR) to a receiving device (sink device, e.g. a television display device) if the receiving device has been authenticated as being a compliant device and if the user of the content has the right to transfer (move, copy) that content to another device. If transfer of content is allowed, this will typically be performed in an encrypted way to make sure that the content cannot be captured in an unprotected, high-quality digital format.

Technology to perform device authentication and encrypted content transfer is available and is called a secure authenticated channel (SAC). In many cases, a SAC is set up using an Authentication and Key Exchange (AKE) protocol that is based on public key cryptography. Standards such as International Standard ISO/IEC 11770-3 and ISO/IEC 9796- 2, and public key algorithms such as RSA and hash algorithms like SHA-I are often used.

To set up a SAC, each device typically contains a unique encryption key that is used in a challenge/response protocol with another device to calculate a temporary, mutually shared key. The two devices subsequently use this shared key to protect the exchanged content and usage rights information. A remaining issue is that a SAC may be set up between devices that are, physically or network- wise, far away from each other. To limit this possibility, various proposals have been made for some form of distance measurement that is to be performed when the SAC is set up. If the source and sink devices are too far away from each other, the SAC should not be set up or content exchange should be refused or limited. Typically such distance measurement involves a challenge-response protocol where the time between sending the challenge and receiving the response is measured and used to estimate the distance between source and sink devices. Distance measurement can be combined with the authentication protocol of the SAC setup, as is taught for example in international patent application WO 2004/014037 (attorney docket PHNL020681).

A problem with distance measurement protocols, especially those that combine distance measurement with authentication, is that the time between sending the challenge and receiving the response also includes the time needed by the remote party (typically the sink device) to compute the response. This may introduce inaccuracies in the determined distance. For instance, a personal computer with a fast processor can compute a response very quickly, even when (complex and hence slow) public key cryptography operations are used. A small portable device such as a PDA will take a much longer time to perform the same computations. It is now hard to tell the difference between such a fast PC that is far away and such a slow portable device that is closer.

It is an object of the present invention to provide a method of determining a distance between a first device and a second device which improves upon the above methods. This object is achieved according to the invention in a method comprising, in a precomputing phase, at both devices (200, 220), computing for a query α, a protected query Ma₁ and for a response bi a protected response Wb₁, and in an interactive phase,

- at the first device (200), sending the protected query Ma₁ to the second device (220),

- at the second device (220), comparing the received protected query Ma₁ against the computed protected query Ma₁, - at the second device (220), sending the protected response mbj to the first device (200), at the first device (200), comparing the received protected response mbj against the computed protected response mbj, and determining the distance based on a measurement of time elapsed between sending the protected query Ma₁ to the second device (220) and receiving the protected response Mb₁ from the second device (220).

In this method, the protocol interactions are minimized. The only complex operations are during the precomputing phase. If, as is preferred, only symmetric cryptographic functions are used to derive the protected queries and responses, the protocol is also very suitable for slow devices such as the above-mentioned PDAs. Moreover the present invention is suitable for use in any connection between two devices where there is a need to determine the physical proximity of the connected devices. There is a clear separation from any other protocol, such as the establishment of a secure authenticated channel. The most important feature of the present invention is that the time difference that is measured at the end of the interactive phase relates only to the travel time of the protected query and response between the devices and not to the processing power of the devices. This is due to the precomputation phase which is executed before the interactive phase. Any time spent on computing the protected versions of queries and responses is not counted in the time between sending the protected query and receiving the protected response, because these computations occurred before the interactive phease.

International patent application WO 2003/079638 (attorney docket

PHUS020086) mentions that the time between query and reply comprises both the time for communicating the query and its reply and the time needed for computing the reply. The document further suggests to subtract the processing time from the measured time between sending the query and receiving the reply. However, this requires that the processing time is known with a sufficient degree of accuracy.

International patent applications WO 2004/030311 (attorney docket PHUS010314) and WO 2004/030312 (attorney docket PHUS020358) also deal with estimating the distance between two devices by measuring the time between sending a query and receiving a reply. Both assume that the processing time for computing the reply is negligible compared to the time needed for the query and reply to travel over the network. Both hence conclude that a device is "far away" if the time between sending a query and receiving a reply exceeds a certain threshold. As argued above, these applications thus would wrongly conclude a very slow device is far away because its long processing time is taken for a large network travel time.

Preferably the queries and responses are computed by applying a cryptographic hash function to a given seed R. This is an easy and fast way to compute these queries and response. Furthermore, if the parties engage in the setting up of a secure authenticated channel, the SAC setup protocol may produce as one of its outputs a number that may serve as the seed R. This number will be hard to predict for an outside attacker. This embodiment thus improves security of the system.

Preferably the protected version Ma₁ of a query α, and the protected version mbj of a response b_l are computed using a Message Authentication Code (MAC) function. Optionally the protected query Ma₁ and the protected response mbj are sent accompanied by the number i. This ensures that the recipient knows which computed query and response to compare against the received query and response, respectively. As a result it is more likely that the parties will remain synchronized throughout the protocol.

Other advantageous embodiments are set out in the dependent claims. The invention further provides a system that operates according to the invention, and a first device and a second device for use in this system.

The invention will now be discussed in more detail with reference to the figures, in which:

Fig. 1 schematically shows a system comprising devices interconnected via a network;

Fig. 2 schematically illustrates a source device and a sink device; and Fig. 3 shows an embodiment of the inventive proximity detection protocol.

Throughout the figures, same reference numerals indicate similar or corresponding features. Some of the features indicated in the drawings are typically implemented in software, and as such represent software entities, such as software modules or objects.

Fig. 1 schematically shows a system 100 comprising devices 101-105 interconnected via a network 110. A typical digital home network includes a number of devices, e.g. a radio receiver, a tuner/decoder, a CD player, a pair of speakers, a television, a VCR, a digital recorder, a mobile phone, a tape deck, a personal computer, a personal digital assistant, a portable display unit, a car entertainment system, and so on. These devices are usually interconnected to allow one device, e.g. the television, to control another, e.g. the VCR. One device, such as e.g. the tuner/decoder or a set top box (STB), is usually the central device, providing central control over the others. Content, which typically comprises things like music, songs, movies, animations, speeches, videoclips for music, TV programs, pictures, games, ringtones, spoken books and the like, but which also may include interactive services, is received through a residential gateway or set top box 101. Content could also enter the home via other sources, such as storage media like discs or using portable devices. The source could be a connection to a broadband cable network, an Internet connection, a satellite downlink and so on. The content can then be transferred over the network 110 to a sink for rendering. A sink can be, for instance, the television display 102, the portable display device 103, the mobile phone 104 and/or the audio playback device 105. The exact way in which a content item is rendered depends on the type of device and the type of content. For instance, in a radio receiver, rendering comprises generating audio signals and feeding them to loudspeakers. For a television receiver, rendering generally comprises generating audio and video signals and feeding those to a display screen and loudspeakers. For other types of content a similar appropriate action must be taken. Rendering may also include operations such as decrypting or descrambling a received signal, synchronizing audio and video signals and so on.

The set top box 101, or any other device in the system 100, may comprise a storage medium Sl such as a suitably large hard disk, allowing the recording and later playback of received content. The storage medium Sl could be a Personal Digital Recorder (PDR) of some kind, for example a DVD+RW recorder, to which the set top box 101 is connected. Content can also enter the system 100 stored on a carrier 120 such as a Compact Disc (CD) or Digital Versatile Disc (DVD).

The portable display device 103 and the mobile phone 104 are connected wirelessly to the network 110 using a base station 111, for example using Bluetooth or IEEE 802.1 Ib. The other devices are connected using a conventional wired connection. To allow the devices 101-105 to interact, several interoperability standards are available, which allow different devices to exchange messages and information and to control each other. One well- known standard is the Universal Plug and Play (http://www.upnp.org) standard.

It is important to ensure that the devices 101-105 in the home network do not allow the creation of unauthorized copies of the content. Hence the devices 101-105 are provided with a data protection system for a digital display interface. This data protection system ensures that only authorized and protected content transfers can occur from a first device, hereafter referred to as source device or just source, to a second device, hereafter referred to as sink device or just sink. Fig. 2 schematically illustrates a source device 200 and sink device 220. Both devices comprise a digital interface IF, a processor CPU and a storage component MEM. Typically the source device 200 is a device that holds content which is to be streamed (or otherwise transmitted) to the sink device 220. The sink device 220 then typically is a device that receives this streamed content and renders it, e.g. on a display screen. Any of the devices 101-105 mentioned above may operate as the source device 200 and/or as the sink device 220. It is worth noting that a device may operate as source device relative to one other device, and as sink device relative to a further device. This may even occur simultaneously. An example of a source device 200 and a sink device 220 is a digital video recorder (DVR) connected to a television display. The digital audiovisual content recorded by the DVR is streamed to the display so the user can watch the content. The source may also be a (laptop or desktop) computer, where the sink is its display screen.

As shown in Fig. 2, the interface between source device 200 and sink device 220 comprises a high-speed unidirectional main link 211 and a relatively low-speed bidirectional auxiliary channel 212. In an embodiment evisaged by the inventors, the main link 211 can carry up to 10 Gigabits per second and the auxiliary channel 212 has a 1 Megabit per second transfer rate. The main link 211 is used to carry compressed or uncompressed digital data such as video and/or audio data. Technology to perform device authentication and encrypted content transfer is available and is called a secure authenticated channel (SAC). A SAC 210 is assumed to have been set up as shown in Fig. 2 to protect the data transferred over the main link 211 and auxiliary link 212. Alternatively only the main link 211 or only the auxiliary link 212 may be protected by the SAC 210. For example, if the content to be transferred is already encrypted, there is no need to transfer the content over a SAC as that would mean needless double encryption operations. Yet alternatively the SAC may for some message transfers be bypassed, for example for already-encrypted messages or for messages that can safely be sent without protection.

SACs and the underlying technologies are well-known. Public key cryptography and digital certificates may be used for mutual authentication between the source and sink devices. The data is transferred over the main link in encrypted form.

It is assumed is that the source and sink devices have already established the secure authenticated channel 210. Many ways are possible to establish a SAC. Which particular technique is chosen is out of scope for the present invention. It is also assumed that both devices share a common secret authentication key (denoted by K) and another common secret (referred as seed and denoted by R). Those values are preferably computed or exchanged during the SAC establishment phase.

An embodiment of the inventive proximity detection protocol is illustrated in Fig. 3. The proximity detection protocol consists of a pre-computation phase and an interactive phase. During the precomputation phase, the devices compute the information they will use during the interactive phase. Each phase of the protocol is now described in turn.

During the precomputation phase, both devices obtain at least one query and at least one corresponding response. In a preferred embodiment both devices compute a sequence of queries, hereafter referred to as the sequence a, and a sequence of responses, hereafter referred to as the sequence b using the above-mentioned seed R and a public algorithm. Elements of the sequences are referred to as Ci₁ and b_t respectively, where i is an integer ranging from 0 to a certain (sufficiently large) maximum N. The queries and responses can simply be binary sequences.

For security reasons, both devices must ensure that none of the values Ci₁ equal any of the values b_t. Mathematically speaking, V/, je {O,..., N}: Ci₁ ≠ b .

The sequences a and b may be computed in many ways. An efficient way to generate the sequences is to apply a cryptographic hash function to the seed R and the integer i (i = 0, ..., N) to generate Ci₁ and b_t. For instance:

where 'x||y' denotes concatenation of the string x and the string y. The cryptographic hash function preferably is the well-known SHA function. In this embodiment the sequences are unknown to third parties.

Another way to compute the items Ci₁ and b_l (i = 0, ..., N) is to simply determine a number BN that is larger than N and to determine the items as: ai = i bi = i + BN If this embodiment is used, the sequences themselves are known to or can easily be predicted by third parties.

In the above embodiment the seed R is not used. This makes the embodiment useful if the SAC protocol does not deliver such a seed R. If it is desirable to use the seed R, another way to compute the items Ci₁ and b_l (i = 0, ..., N) is to determine the items as: ai = R + i bi = R + i + BN Alternatively the sequences a and b may be provided to the devices 200, 220 from an external source. For instance the sequences may have been preprogrammed or received from a domain manager.

Next, both devices compute protected versions of all items Ci₁ and b₁ {i = 0, ..., N), denoted as ma, and Mb₁ respectively. It should not be possible to derive mb_t from Ma₁ without the knowledge of the authentication key K. Preferably the protected versions are generated using a Message Authentication Code (MAC) function using a MAC such as AES in XCBC mode as follows: Ma₁ = MAC(K, ai) mb, = MAC(K, b,)

Alternatively a HMAC using a cryptographic hash function such as SHA can be used. The use of the MD5 hash function is theoretically possible, but this function has been shown to be insecure. As alternatives to a MAC, the protected versions could be created by applying a digital signature algorithm to the items. If it is not necessary that the sequences a and b can be made public, then a straightforward use of a hash function (i.e. ma_t = SHA(α,) and Mb₁ = SHA(^)) can be made instead. By using a keyed MAC or a digital signature algorithm, it is possible to publish the sequences a and b and still have a secure protocol.

Both devices further have a counter to keep track of the current query and response. This counter is denoted by i.

The precomputing phase may occur at any time prior to the interactive phase. If the common secret authentication key K and the seed R (or one of these values) are established during the SAC setup, then of course the precomputing phase should occur after setting up the SAC. If however the inputs needed for the precomputing phase are not established during the SAC setup, then the precomputing phase may occur at any time. By performing these computations prior to the interactive phase, it is ensured that any time spent on these computations does not affect the time measured in the actual distance measurement protocol. This way the time measured is the most accurate.

The second phase is interactive and illustrated in Fig. 3. Initially, both devices have stored respective copies ofa_h b_u ma_b mb_u and i which were computed in the first phase. In step 301, source device 200 records the current time, hereafter referred to as t₀.

In step 302, source device 200 sends Ma₁ to sink device 220 which receives it in step 303. In step 304, sink device 220 verifies that the received value Ma₁ is equal to the stored value Ma₁. As this involves only a comparison between two numbers, this can be done very efficiently. If the received value does not match the stored value, the sink aborts the protocol in step 320.

In step 305, sink device 220 responds by sending the value mb_t back to the source device 200. The source device 200 receives this value mb_t in step 306 and verifies in step 307 that the received value Mb₁ is equal to the stored value mb_t.

Both devices 200, 220 subsequently increase their counters i by one in steps 308, 309. The counters ensure that both devices use the same values Ma₁ and Mb₁ in the protocol. It may happen that the respective counters from the devices 200, 220 have different values. For example, a device may crash after completing the message exchange but before the counter could be updated. If the other device does update the counter, then subsequent distance measurements will fail because the comparison of the received Ma₁ or Mb₁ and the stored Ma₁ or Mb₁ will reveal they are not identical.

To detect this kind of problem, it is possible for the device performing the check to compare the received protected value, say Ma₁, against not only the stored Ma₁, but also against the previous and next items in the sequence, ma₁₊i and Ma₁-I. If there is a match between the received value ma, and ma₁₊i or Ma₁-I, the device can adjust its counter appropriately.

An alternative solution to this problem is to send the counter i along with the value THa₁ (or Mb₁). This way the recipient immediately knows against which stored value the received value is to be compared.

Source device 200 in step 310 again records the current time, hereafter referred to as ti. In step 311 the source device 200 computes the time difference ti - to. This time difference is used in the final step 312 to determine if the sink device 220 is sufficiently close to the source device 200. This is preferably done by determining if the time difference is less than a predetermined limit.

This determination can be used to decide whether the sink device 220 is to be authenticated or not, or whether particular content is allowed to be transferred to the sink device 220. For instance, a requirement could be that any query is to be answered within7 milliseconds. This is sufficiently short to know with reasonable certainty that the sink device 220 must be close to the source device 200. The choice depends on many parameters, such as the expected travel time of data over the network. In the abovementioned network where the auxiliary channel 212 has a 1 Megabit per second transfer rate, the inventors prefer a value of 500μs. At regular intervals during data transfer the proximity detection may be repeated to verify whether the source device 200 and the sink device 220 are still in the required proximity of each other.

It is worth noting that even though there is a secure authenticated channel 210 between the devices 200, 220, the proximity protocol according to the invention does not need to be carried out over this secure authenticated channel 210. It may be carried out over the auxiliary channel 212 without protecting the messages.

It should be noted that the above-mentioned embodiments illustrate rather than limit the invention, and that those skilled in the art will be able to design many alternative embodiments without departing from the scope of the appended claims.

In the claims, any reference signs placed between parentheses shall not be construed as limiting the claim. The word "comprising" does not exclude the presence of elements or steps other than those listed in a claim. The word "a" or "an" preceding an element does not exclude the presence of a plurality of such elements. The invention can be implemented by means of hardware comprising several distinct elements, and by means of a suitably programmed computer. In the device claim enumerating several means, several of these means can be embodied by one and the same item of hardware. The mere fact that certain measures are recited in mutually different dependent claims does not indicate that a combination of these measures cannot be used to advantage.

Claims

CLAIMS:

1. A method of determining a distance between a first device (200) and a second device (220), the method comprising: in a precomputing phase, at both devices (200, 220), computing for a query Ci₁ a protected query ma, and for a response b_t a protected response Mb₁, in an interactive phase, at the first device (200), sending the protected query ma, to the second device (220), at the second device (220), comparing the received protected query ma, against the computed protected query Ma₁, at the second device (220), sending the protected response mbj to the first device (200), at the first device (200), comparing the received protected response Mb₁ against the computed protected response mb_t, and determining the distance based on a measurement of time elapsed between sending the protected query Ma₁ to the second device (220) and receiving the protected response mb_t from the second device (220).

2. The method of claim 1 , in which the step of computing the protected query is performed once for each query α, of a given first sequence a of queries, and the step of computing the protected response is performed once for each response b_l of a given second sequence b of responses a protected response mb_t, where i is a number between 0 and a predetermined boundary N.

3. The method of claim 1 or 2, in which the query Ci₁ is computed by applying a cryptographic hash function to a given seed R and the number i, and the response b_l is computed by applying a cryptographic hash function to a given seed R and the number i, such that Ci₁ does not equal b_l.

4. The method of claim 3 as dependent from claim 2, in which each query Ci₁ of the given first sequence a of queries is computed by applying a cryptographic hash function to a given seed R and the number i, and each response b_l of a given second sequence b of responses is computed by applying a cryptographic hash function to a given seed R and the number i, such that for each query α, and for each response b_u Ci₁ does not equal b_l.

5. The method of claim 2, in which the first sequence a of queries and the second sequence b of responses are received by the devices (200, 220) over a network.

6. The method of claim 1 , in which the protected version Ma₁ of a query Ci₁ and the protected version Wb₁ of a response b_t are computed using a Message Authentication Code (MAC) function.

7. The method of claim 2, in which the protected query Ma₁ and the protected response Mb₁ are sent accompanied by the number i.

8. A system comprising a first device (200) and a second device (220) and being configured for determining a distance between the devices (200, 220), in which both devices (200, 220) comprises respective means (CPU, MEM) for, in a precomputing phase, computing for a query α, a protected query Ma₁ and for a response b_l a protected response mbj, the first device (200) comprises means (CPU, MEM, IF) for, in an interactive phase, sending the protected query Ma₁ to the second device (220), the second device (220) comprises means (CPU, MEM, IF) for, in the interactive phase, comparing the received protected query Ma₁ against the computed protected query Ma₁, and means (CPU, MEM, IF) for sending the protected response Mb₁ to the first device (200), the first device (200) further comprises means (CPU, MEM, IF) for, in the interactive phase, comparing the received protected response Mb₁ against the computed protected response mbj, and means (CPU) for determining the distance based on a measurement of time elapsed between sending the protected query Ma₁ to the second device (220) and receiving the protected response mbj from the second device (220).

9. A device (200) configured to operate as the first device as claimed in claim 8, comprising means (CPU, MEM) for, in a precomputing phase, computing for a query a_t a protected query Ma₁ and for a response b_t a protected response Mb₁, means (CPU, MEM, IF) for, in an interactive phase, sending the protected query Ma₁ to a second device (220), means (CPU, MEM, IF) for, in the interactive phase, receiving a protected response mb_t and for comparing the received protected response mb_t against the computed protected response

and means (CPU) for determining the distance based on a measurement of time elapsed between sending the protected query Ma₁ to the second device (220) and receiving the protected response Mb₁ from the second device (220).

10. A device (220) configured to operate as the second device as claimed in claim 8, comprising means (CPU, MEM) for, in a precomputing phase, computing for a query a_t a protected query Ma₁ and for a response b_l a protected response mbj, means (CPU, MEM, IF) for, in an interactive phase, receiving a protected query Ma₁ from the first device (210) and for comparing the received protected query Ma₁ against the computed protected query Ma₁, and means (CPU, MEM, IF) for sending the protected response Wb₁ to the first device (200).

11. A device (200, 220) configured to operate as both the device of claim 9 and the device of claim 10.