MXPA06010446A - Method of and device for generating authorization status list - Google Patents

Abstract

A method of generating an authorization status list, comprising generating a run-length encoded representation of an authorization status of a number of devices and storing the representation in the authorization status list. Preferably comprises generating the representation by indicating, for each of a number of ranges of devices, the devices in a particular .range having a same authorization status, the number of devices in each of said ranges, together with for each of said ranges the authorization status shared by the devices in each of said ranges. A range may then be omitted if it is of a predetermined length.

Description

METHOD AND DEVICE FOR GENERATING A LIST OF AUTHORIZATION STATUS DESCRIPTION OF THE INVENTION In recent years, the amount of content protection systems has grown at a rapid pace. Some of these systems only protect the content against. the illegal copy while others also prohibit the user from accessing the content. The first category is called the Copy Protection System (CP) and has traditionally been the main focus for Consumer Electronics (CE) devices, because it is thought that this type Content protection can be implemented in a non-expensive way and does not need a bidirectional interaction with the content provider. Examples are the CSS (Content Alteration System), the protection system of DVD ROM and DTCP (Protection of Digital Transmission Content), the protection system for IEEE 1394 connections. The second category is known by several names. In the world of transmissions are generally known as CA systems (Conditional Access), while in the world of the Internet they are generally known as DRM systems (Administration of Digital Rights). The protection systems usually include Ref .: 174327 protected communication between devices based on some secret, only known by the devices that were tested and certified to have secure implementations. Knowledge of the secret is tested using an authentication protocol. The best solutions for these protocols are those that use public key cryptography, which uses a different pair of keys. The secret to be tested is then the secret key of the pair, while the public key can be used to verify the results of the test. To ensure that the public key is correct and to verify if the key pair is a legitimate pair of a certified device, the public key is accompanied by a certificate, which is digitally signed by a Certification Authority (CA). English), whose organization manages the distribution of public / private key pair for all devices. Everyone knows the public key and can use it to verify the signature of the CA on the certificate. In a simple implementation the public key of the CA is embedded in the code in the implementation of the device. To enable this process, each hardware device or software application (collectively referred to as devices hereafter) maintains a number of secret keys, sometimes referred to as private keys. These keys and the control flow that uses these keys must be well protected, the knowledge of these keys or the manipulation of the flow of control would allow the hackers to circumvent the content protection systems. In typical security scenarios, there are several different devices involved, the. which may not all be implemented with equal levels against alteration. Therefore, such a system will have to be resistant to the hacking activity of individual devices, which could allow the illegal storage, copying and / or redistribution of digital content. However, it is likely that during the lifetime of a product type that makes use of the system, some or even many devices will be hacked in some way. An important technique is to increase the resistance of the so-called revocation of these pirated devices. This requires that all devices read a so-called Certificate Revocation List (CRL), a list that allows the identification of revoked devices. Compliant devices are bound in some way to possess an updated CRL, and should never pass the content to devices that are listed in the CRL. The CA generates and distributes new CRLs whenever necessary. The revocation may be indicated in several different ways. Two different techniques that can be used are called blacklists (lists of revoked devices) or white lists (list of non-revoked devices).

Typically all devices in the content protection system have mutually different identifiers installed in the factory. Alternatively, an authorized domain management device can assign unique identifiers to devices when joining the authorized domain. These identifiers can be used in the CRL instead of globally unique identifiers. The difference between white lists and blacklists lies in their interpretation and use: in order that a "Verifier" certifies that a "Tester" that wants to authenticate with the Verifier is not in fact revoked, in the case of blacklists, the Verifier will have to obtain the complete blacklist. In the case of whitelists, the Verifiers need as proof of non-revocation only the part of the white list that refers to the Public Key or ID of the Tester. Therefore, the white-listing scenario has important advantages in terms of storage and bus transmission in content protection systems, especially in scenarios such as a PC guest application that authenticates a peripheral device such as an optical drive with little power of computation: processing. However, with this advantage comes a disadvantage: a simple white listing requires each device / application to obtain its own certificate attesting to its non-revocation status, with a huge excess of network usage or disk storage. To mitigate this problem, WO 003/107588 (number control proxy PHNL020543) and international patent application WO 003/107589 (control number PHNL020544 proxy) introduced a Certificate Groups (GC, for short English) that is provided by the Verifier. The GC is a concise proof of the fact that one or more groups - one of those belonging to the Tester - is authorized, for example to access certain content under the control of the Verifier or to perform some other operation such as starting a session in a network. This same GC can be used by many devices / applications (in fact all the devices / applications mentioned in the GC). Group certificates in accordance with these patent applications indicate in one modality the upper and lower limits of each group presented in the GC. When a device in a particular group loses its status as an authorized device, one or more new group certificates must be generated. Also to indicate these limits are the device identifiers. Such identifiers can be very large since they often have to be globally unique. This makes group certificates very large if there is a large number of groups. The parsing of these group certificates can also be difficult, especially through hardware devices with low memory and computing capacity. An object of the present invention is to provide a method of generating a list of authorization status that provides on average a representation of the authorization status of the devices in the shorter list than in the prior art methods. This object is achieved according to the invention in a method comprising the generation of a coded length-execution representation of an authorization status of a number of devices and the storage of the representation in the authorization list. The invention is based in part on the following ideas: With very high probability, the IDs of the newly manufactured devices will be revoked. - Software devices are more vulnerable to piracy than hardware. Older software devices have a high probability of having the status "revoked". When the revocation occurs, it will include a legal action. This represents a substantial threshold and therefore the number of revocation events will be limited. In addition, the likely result of such legal revocation actions is that it will be revoked - a single device or a contiguous range of devices (for example, a model / type from the same manufacturer or software company). Theft of discs that contain ID / Public Keys / Private Keys of new devices (typically a block of numbers) for distribution to unit manufacturers and software companies. When this robbery is discovered, the Certification Authority revokes all these device IDs (contiguous). As a result, authorization status lists are expected to contain: long ranges of non-revoked devices, long ranges of revoked devices, isolated single revoked devices between long ranges of non-revoked devices, and simple isolated non-revoked devices between long ranges of revoked devices Length-execution encoding will ensure that these long ranges of devices all with the same authorization status are represented efficiently. In one embodiment, the method comprises generating the representation by indicating, for each of a number of device ranges, the devices in a particular range that have the same authorization status, the number of devices in each of those ranges. This is a very efficient way of performing length-execution encoding of authorization status information that does not require much processing for decoding. Preferably, the authorization status shared by the devices in each of the ranges is indicated in the list of authorization status for each of these ranges. This can be done using a single bit, for example, the binary value l 'indicates that the device is not authorized and the binary value? 0' indicates that the device is authorized. Preferably in the list of authorization status for each of the ranges a limit of the ranges is indicated, for example a device identifier lower and / or higher in the ranges. If the ranges are consecutive, the lowest identifier in the lowest range and / or the highest identifier in the highest range can be used. This clarifies to which devices the list applies. This list can indicate for plural ranges the respective numbers of devices in each of those ranges. If a second rank is successive to a first rank, then it must be ensured that the first authorization status differs from the second authorization status. This provides a very efficient length-execution encoding, because it is now possible to omit the indication of the status information. If the status is of a known range, then the status of all others can be derived by their order in relation to the range. Preferably a range is omitted if it is of a predetermined length. It is more likely that short ranges of revoked devices will occur, especially ranges of length one (ie, individual devices revoked), than long ranges. Therefore, by omitting indications of such ranges can achieve substantial savings. A device that parses the list can derive the status of the device (s) in such a range because it will be preceded and followed by ranges that have the same authorization status. This can only happen if there was a range with opposite authorization status, and therefore the range must have been omitted. These and other aspects of the invention will be evidenced and explained with reference to the illustrative embodiments shown in the figures, in which: Figure 1 shows schematically a system comprising devices interconnected via a network; Figure 2 schematically shows a server arranged to generate a list of authorization status in accordance with the invention; Figure 3 illustrates a preferred implementation of a list of authorization status; Figure 4 schematically shows an exemplary embodiment of the invention in which a source device authenticates a sink device; and Figure 5 shows schematically a request / response protocol to establish a Secure Atynticated Channel (SAC)., by its acronym in English) which involves the use of a list of authorization status in accordance with the invention. Throughout the figures, the same reference numbers indicate similar or corresponding characteristics. Some of the features indicated in the drawings are typically implemented in software, and as such represent software entities, such as modules or software objects. Figure 1 schematically shows a system 100 comprising the devices 101-105 interconnected via a network 110. A typical home digital network includes a number of devices, for example, 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 player, a personal computer, a personal digital assistant, a portable display unit, etc. These devices are usually connected to allow one device, for example, the television, to control another, for example / the video recorder. A device such as for example the tuner / decoder or a decoder receiver apparatus (STB), is usually the central device, providing central control to the others. The system 100 can be an internal home network that operates as an Authorized Domain. In this type of content protection systems (such as Thomson SmartRight, or DTLA DTCP) a set of devices can authenticate each other through a bidirectional connection. Based on this authentication, the devices will trust each other and this will allow them to exchange protected content. In the licenses that accompany the content, it describes what rights the user has and what operations he is allowed to perform on the content. Some particular architectures of authorized domains have been outlined in the international patent application WO 03/098931 (control number of the proxy PHNL020455), in the European patent application serial number 03100772.7 (proxy control number PHNL030283), in the application of European patent serial number 03102281.7 (control number of the proxy PHNL030926), in the European patent application serial number 04100997.8 (control number of the proxy PHNL040288) and in F. Kamperman and W. Jon er, P. Lenoir, and B. vd Heuvel, Secure content management in authorized domains (Administration of secure content in authorized domains), Reports IBC2002, pages 467-475, September 2002. The authorized domains need to address issues such as authorized domain identification, verification of entry of devices, device exit verification, rights entry verification, rights exit verification, verification Content entry notification, content exit verification, as well as domain administration. The content, which typically comprises such things as music, songs, movies, TV shows, images, games, books and the like, but which may also include interactive services, is received through a residential gateway or decoder receiver apparatus 101. The content It could also enter the home through other sources, such as storage media such as discs or using portable devices. The source could be a connection to a broadband cable network, a connection to the Internet, a satellite downlink, etc. The content can then be transferred through the network 110 to a sink for representation. A sink can be, for example, the television screen 102, the portable display device 103, the mobile telephone 104 and / or the audio reproduction device 105. The exact form in which an article of content is represented depends on the type of device and the type of content. For example, in a radio receiver, the representation comprises the generation of audio signals and the feeding thereof to loudspeakers. For a television receiver, the representation generally comprises generating audio and video signals and feeding them to a display screen and speakers. For other types of content, a similar appropriate action should be taken. The representation may also include operations such as deciphering or desalting a received signal, synchronizing audio and video signals, etc. The decoding receiver 101, or any other device in the system 100, may comprise a storage medium SI such as a suitably large hard disk, allowing the recording and subsequent reproduction of the received content. The storage medium SI could be a Personal Digital Recorder (PDR) of some kind, for example a DVD + RW recorder, to which the decoder receiver 101 is connected. The content can also enter the system. 100 stored in a carrier 120 such as a Compact Disc (CD) or Digital Verbatim Disc (DVD). The portable display device 103 and the mobile telephone 104 are connected wirelessly to the network 110 using a base station 111, for example using Bluetooth or IEEE 802.11b. The other devices are connected using a conventional wired connection. To allow the 101-105 devices to interact, several interoperability standards are available, which also allow different devices to exchange messages and information and to control each other. A well-known standard is the Audio / Video Interoperability (HAVi) standard, version 1.0 which was released in January 2000, and is available on the Internet at http: // www. havi.org/ Other well-known standards are the domestic digital bus standard (D2B), a communications protocol described in IEC 1030 and Universal Plug and Play (http://www.upnp.org). It is often important to ensure that the 101-105 devices in the home network do not make unauthorized copies of the content. For this, an integrated database payment is necessary, typically called Digital Rights Management (DRM, for its acronym in English). One way to protect content in the form of digital data is to ensure that content will only be transferred between devices 101-105 if: the receiving device has "been authenticated as a compliance device, and - the content user has the right to Transfer (move and / or copy) that content to another device If the transfer of content is allowed, this will typically be done in an encrypted form to ensure that the content can not be illegally captured in a useful format of the transport channel, such as a bus between a CD-ROM drive and a personal computer (guest) .The technology for performing device authentication and encrypted content transfer is available and is called secure authenticated channel (SAC). In many cases, an SAC is configured using an Authentication and Key Exchange protocol (AKE, for its acronym in English) that is based on public key cryptography. Standards such as International Standard ISO / IEC 11770-3 and ISO / IEC are frequently used 9796-2, and public key algorithms such as RSA and dispersion algorithms such as SHA-1. Figure 2 schematically shows a server 200 arranged to generate a list of authorization status in accordance with the invention. This list can then be subsequently used by devices such as the devices 101-105 to verify if their communication partners are still authorized to communicate with them. The invention assumes that the devices have respective identifiers. These identifiers are arranged in a particular order. A very direct way to do this is to assign to the first device the identifier "1", to the second the identifier "2", etc. If the device identifiers by themselves are non-contiguous, for example, if they are a randomly chosen alphanumeric string, a correlation could be made with a sequential order. The authorization status list reflects the authorization status of a number of devices. This number could be of all devices, but is preferably chosen as a subset. If chosen as a subset, it is advantageous to indicate in the list one or more limits of the subset, for example the lower and / or higher identifiers or the lowest device identifier together with an indication of the size of the subset. The subset can be chosen to correspond to a predefined group of devices. For example, a group of devices manufactured by the same entity, or in a particular period could be covered by a single list of authorization status. The authorization status is determined for each applicable device identifier. This status can be as simple as "authorized" versus "unauthorized" or it can be more complex. For example, a list of authorization status could indicate that a particular device should no longer communicate at all, or that only content of lower value should be provided to that particular device. If a simple double-status status is employed, a single bit can be used in the authorization status list to represent it. The server 200 may comprise a database 210 indicating the authorization status of the devices for which the authorization will be generated. authorization status list. When a device is "authorized" or not depends on the application, it could mean that it has been established that the device is in compliance with a certain set of requirements or • a certain standard. It could mean that the device is authorized to access, copy, move, modify or delete certain content that can perform some other operation such as logging into a network. The server 200 then activates the length-execution coding module 220 to generate a length-execution representation of these authorization statuses. In a preferred embodiment, the module 220 identifies ranges of devices that have the same authorization status. A range is a set of successive items in the order used for the device identifiers.

The module "220" could for example determine that the devices with the identifiers 1-53 are authorized, that the devices 54-69 are not authorized, that the device 70 is authorized, that the devices 71-89 are not authorized and that the devices 90-100 are authorized For each range the module 220 then generates an indication of the number of devices in that range In the example of the last paragraph, the server 200 could indicate in the list of authorization status the numbers 53, 16.1 19, 11. It is clear that this form of length-execution compression presents a great reduction in comparison with indicating for each of these 100 devices their status separately. . The coded representation is then fed to the '230 lists' generation module., which "creates a list of authorization status comprising this coded representation." Preferably, the module 230 indicates with each number the applicable status, for example "1:53, 0:16, 1: 1, 0:19, 1: 11. Alternatively, an indication could be provided, for example in the header, of the authorization status of the first indicated range.A device that parses this list can then assume that the second rank has a status opposite to the indicated status, the third rank a status equal to the indicated status, the fourth again opposite, etc. This has the advantage that only one indication of status needs to be provided even when a large number of ranges are included, it could be agreed in advance that the first range indicated is always considered to be authorized or not authorized, this means that no single indication of status needs to be provided, however, this creates the problem that the first In the first rank, it could eventually end up with an authorization opposite to the agreed status. To solve this problem the first identifier could be declared reserved in such a way that it will never be assigned to any device. For example, suppose that it is agreed that the first indicated range will always be considered authoritative. At the beginning, all devices are authorized in such a way that the authorization list could be as simple as "1-100". At some point in time the first ten device identifiers will be declared no longer authorized. Then a new authorization list is generated, indicating "1, 10, 89". This can be interpreted as "the first ten device identifiers • are not authorized and the next 89 are authorized", since the first of the indications only covers the reserved device identifier. Further improvement can be obtained by omitting a predetermined length range. Preferably, this predetermined length is chosen to be equal to 1. It may be desirable to indicate in the authorization status list the value of this predetermined length. In the example under discussion, the omission ranges of length 1 could result in the indication of "1:53, 0:16, 0:19, 1:11" in the list. The omitted range can be detected from the fact that two consecutive ranges with the same authorization status have been indicated. If there were no devices between them with a different status, these two ranges could have been indicated as a simple range. The number of devices in a particular range can be indicated using a fixed number of bits. It may be advantageous if the module 230 determines which is the highest number and determines the number of bits that are needed to represent this number. This number of bits can then be indicated in the list. This avoids the situation that for example 32 bits are used to encode each number of devices in each particular range, of which 16 are wasted because no range comprises more than two for the power of 16 devices. Multiple lists could be combined into a single data element, such that such element covers multiple non-consecutive ranges of device identifiers. In this case the header of the data element could provide an indication of the respective covered ranges, for example "1-100, 120-140, 250-290". This "allows easy filtering by the devices receiving this data element." Module 230 could digitally sign the authorization status list or otherwise protect it, for example by attaching a code message authentication code (see Internet RFC 2104) Figure 3 illustrates a preferred implementation The authorization status of all devices ranging from a "first address" to a "last address" has been determined and is shown at the top., five of which are labeled from or to n5. The remaining two are ranges of length 1, indicating simple devices between longer ranges. The length of these ranges, together with their applicable status is indicated in the list of authorization status shown at the bottom. Each rank and status is indicated using a single word that can be 8, 16, 32 or 64 bits. This number of bits could be indicated in the header. The most significant bit (MSB) of each word is used to indicate the authorization status of the devices in the corresponding range. The other bits of each word are used to indicate the length of these ranges. Length ranges 1 have been omitted. Optionally, the list of authorization status may have a growing monotone generation or version number, and the devices using the list could then be configured to accept only one list if their generation number is greater than some pre-ordered number, for example, stored between the content on a disk, or stored in an NVRAM on the device card. As an alternative to that number, a creation date can be used. Having generated the authorization status list, the server 200 needs to make the information in the list available to the 101-105 devices. This can be done in a variety of ways. The server 200 could transmit the list to the devices 101-105 as a signal via a network using the network module 240, for example at the request of the devices 101-105. The list could also be transmitted periodically. A device that receives the list from server 200 could transmit the list to other devices to which it is connected. It is preferred that when the devices receive authorization status lists, the devices only store the list that relates to the group of which they are members and, consequently, there is a need only for a limited storage size. The server 200 could also record the list to a storage medium, for example an optical recording carrier such as a DVD + RW disc. The medium can then be supplied to devices 101-105. This medium could also have content, be dedicated to the storage of authorization status lists. If the medium is of the variety, rewritable, it is preferred to record the list in an area that quality rewriting devices for the ordinary consumer can not modify. Said area is sometimes known as a "fixed data area", for example as described in the international patent application WO 01/095327. To store data in that fixed area requires the use of components that are typically not available in consumer devices. An example of a technique is to make use of an "oscillation", a radial deviation of the hole positions or the presurco of a perfect spiral in optical discs. Other examples of data stored in fixed data areas are the proposed BCA code for DVD-ROM, selectively damaged points on the disk material burned by high-power lasers, or data stored in a special area of the disk that contains read-only material . The application for 'international patent WO 01/095327 also describes a solution to the problem that the list of authorization status could be too large to fit into a fixed data area. A cryptographic summary, such as an MD5 or an SHA-1 dispersion, from the list of authorization status is calculated and recorded in the fixed data area. Since such a summary is very short (typically 128 or 160 bits), it can easily fit into the fixed data area. The largest list can then be recorded in the (or) area (s) of the disk. The list is only accepted by a conforming device if a summary calculated by the conforming device matches the summary recorded in the fixed data area. In an alternative solution to this problem, WO 01/095327 'suggests recording identification data, for example, a random number, in the fixed data area. The authorization list, a cryptographic summary thereof and the identification data are digitally signed or protected by a message authentication code and stored in the rewritable area (s) of the disk. The server 200 is typically configured as a computing system operated by an entity called Trusted Third Party (TTP), Key Issuance Center (KIC) or Certifying Authority (CA, for its acronym in English). its acronym in English). Such a computing system operates independently of the network 100. In an alternative mode one of the devices 101-105 in the network 100 operates as the server 200 generating the list of authorization status. Preferably, the device operating as an authorized domain administrator generates the list of authorization status and makes it available for the other devices in the authorized domain. The authorized domain administrator may receive a list of authorization status or revocation list in a non-compressed form or in another form that is not suitable for distribution to the devices in the domain. Such a list can potentially be very large, and network 100 could have limited broadband capabilities, or some of the 101-105 devices could have limited processing capabilities and be unable to process such a large list. In cases like that it is advantageous that. the authorized domain administrator generates a list of authorization status in accordance with the present invention of the authorization information received from an external source. This generation of a "local" authorization status list could be done by selecting from the list of "global" authorization status only that information that applies to the devices in the domain. The domain administrator could know for example which device identifiers the devices have in the domain. You can then explore the global list for those identifiers and generate a list of local authorization status that covers those identifiers. The domain administrator could digitally sign the list of local authorization status or protect it in another way, for example by attaching a code message authentication code (see Internet RFC 2104). This allows the devices in the network 100 to accept the list of local authorization status as authentic. The domain administrator can have assigned the devices that join the domain in a local device identifier. In that case, the list of local authorization status could be based on these local device identifiers instead of the global device identifiers. This has the advantage that the local device identifiers are typically chosen from a smaller range than the global device identifiers, which means that the authorization status list will now be much smaller. In an additional optimization scheme, the message part of the certificate is compressed. Message signatures with length m <; C may have the property that the message can be retrieved from just the same signature. Naively someone would think that it is no longer necessary to include the ID groups in the message part of the certificate. However, the filtering of certificates, that is, the decision of which certificate should go to which device, for example, by a gateway device, is then very difficult / expensive, because the processing of the signature is very expensive and could have to be done for each certificate. To help such a filtering device, the following is proposed: the message part of the certificate only needs to contain the IDs of the "lowest" and "highest" groups present in the group of groups (where "lowest" and "highest") "are determined with respect to the order relation). This allows the filter to decide if this certificate could contain a relevant group ID. This can be verified by the target device itself that inspects the signature. This allows the rapid rejection of the set of certificates that are irrelevant. An exemplary embodiment in which a source device authenticates a sink device is illustrated in FIG. 4. In FIG. 4, the source device is a DVD reader / writer unit (DVD + RW) 410 installed in the sink device on the device. which is a personal computer 400. The source device 410 controls access to the content 425 such as a movie recorded on a DVD 420 disc. An application 430 that is executed on the personal computer 400 wants to access this content 425. For this purpose it must communicate with the source device 410, typically through the operating system 440 which establishes an interface between the various components in the personal computer 400. As the content is protected, the source device 410 will only grant the requested access if it can successfully authenticate the sink device 400. Granting access may involve providing content through a bus on the personal computer 400 to the application 430 in a protected or unprotected form. As part of the authorization to access content 425, the usage rights information may need to be updated. For example, a counter indicating how many times the content can be accessed may need to be reduced. A one-time reproduction right may need to be erased or have its status set as 'invalid' or 'used'. You could also use what is called a ticket. See U.S. Patent 6,601,046 (proxy control number PHA 23636) for more information on ticket-based access. This update of the rights of use can be done by means of the source device 410 or by means of the sink device 400. In this authentication process, the source device 410 verifies the revocation status of the sink device 400. For this purpose it comprises a module of authorization status check 415, typically configured as a software program. The authorization status verification module 415 parses the authorization status list to determine whether sink 400 is authorized. For this the module 415 must know a device identifier for the sink device 400. The sink device 400 may have presented a certificate signed by a trusted authority by the source device 410, whose certificate contained this device identifier. Of course other ways of knowing a device identifier are possible. Module 415 then selects a list of authorization status encompassing this device identifier, for example by parsing a header of this list to determine whether this device identifier is included among the lowest and highest device identifiers indicated in this header. The list of necessary authorization status can be obtained in a variety of ways. It may have been supplied via the sink device 400. It could have been read from a storage medium. It may have been received from the server 200, for example, in response to a request by the device 410. In a preferred embodiment, the "tester" (the sink device 400) presents two digitally signed certificates: the last of the authorization status lists, which shows that a group of which the tester is a member, has not been revoked, and a certificate (installed in the factory), which confirms that its device ID (ie, that this device is a member of the group mentioned in the stage referring to the last of the revocation messages Typically, such a certificate contains a device ID and a public key PKi An attacker who has intercepted a certificate for a group of which i is a member and who is trying to pass through i now, will not have the secret key SKi corresponding to PKi and all additional communication will be aborted when this is detected by the verifier, Subsequently the module 415 determines in which range the device identifier This can be done in many ways. One way is to determine a shift between this device identifier and the lowest device identifier applicable to the list of authorization status in question. Module 415 then adds the lengths of the ranges as given in the list until some reach or exceed the offset. Another way is to add the lengths of the ranges to the lowest applicable device identifier until the sum equals or exceeds the device identifier for the sink device 400. In both cases, the range whose length was added at the end to the sum is then the applicable range. In the case that predetermined length ranges are omitted module 415 needs to add this predetermined length whenever it finds a second rank that has the same authorization status as the range whose length was added to the sum. A preferred way of implementing the authorization status lists is now described. The lists of Authorized Groups (AGL, for its acronym in English) are distributed by a Center of Emission of Keys. An AGL shows the authorization status of all devices and applications (with ID = 0 ... 240-l). The AGL is divided into Authorized Groups Certificates (AGC). Each AGC covers a secondary rank of the AGL, that is, a range of devices with contiguous IDs. The authorization status of the devices in this range is specified in each AGC that lists the execution lengths of intervals in which the authorization status for the IDs is identical. Each execution length is preceded by a 1-bit indicator that specifies the status (0 = Authorized to establish an SAC, 1 = other). The "other" status may indicate, for example, that a device has been revoked or its status is unknown. To encode short runs efficiently, two consecutive executions with the same indication value will indicate that _ an interval with the opposite status exists between the two executions. The structure of the certificate data field in the AGC is defined in the following table: The ASCSecNo field contains the Sequence Number of the AGC. The first address is the ID of the first device covered in the AGC. The last address is the ID of the last device covered in the AGC. The number of bytes to be used for the description of execution lengths is specified by means of the AGC Formatting field. An SAC will be established using a request / response protocol shown schematically in Figure 5. In the first stage of this protocol, the Guest and the Device exchange a requirement. The requirement contains Certificates and a random number. In the second stage, both the Guest and the Device verify the authorization of the Public Key Certificate (PKC) verifying that the ID, contained in the PKC, appears in a valid AGC. Valid in this context means that a denoted number - such as AGCSecNo Probe is greater than or equal to a sequence number denoted as VerifierSecNo, whereby the Verifier verifies the novelty of an AGC provided by the Tester and if the ID of the PKC Tester is in reality covered by the AGC. Both the device and the Guest alternately fulfill the role of Verifier / Tester. On each disk, a List of Authorized Groups (AGL). The AGL contains a complete set of AGS provided by the KIC. A VerificadorSec can not be obtained from several sources: - disks other devices conformed network connections In the third stage, both the Guest and the Device generate a response to the request. Subsequently, both the Guest and the Device verify the response received. Authentication is successful only if the answer is correct. In the last stage, both the Guest and the Device calculate a Bus Code of the data in the response. Only the Device and the Guest know the Bus Code. The Bus Key is used to encrypt data that is transferred through the SAC after the SAC establishment protocol ends. It should be noted that the aforementioned embodiments illustrate more 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. The international patent application WO 01/42886 (PHA proxy number 23871) describes an efficient way to combine a contact list and a revocation list. The contact lists may be combined with revocation lists in accordance with the present invention. In order to allow the (probable) possessors of such devices to determine the revocation status of their equipment, the method according to the international patent application WO 03/019438 (proxy control number PHNL010605) can be used. Serial number of European patent application 04100215.5 (proxy control number PHNL040086) describes a method of a source device for authorizing access to content by means of a sink device in accordance with usage rights, the content being stored in a medium storage controlled by the source device. The revocation status of the sink device is verified using the most recently issued revocation information that is available if the usage rights need to be modified as part of the authorization to access the content, and otherwise using revocation information associated with the stored content in the storage medium, preferably the revocation information stored in the storage medium. The revocation information on the storage medium, or only the part that is related to the sink device, is optionally updated to the most recently issued revocation information if the usage rights need to be modified. Preferably this is done if the result of the verification is that the sink device has been revoked. The revocation information as used in the present application could be prepared in accordance with the present invention. In the claims, any reference sign placed between parentheses should not be considered as limiting the claim. The word "comprises" does not exclude the presence of elements or stages different from those listed in the claim. The word "a" or "an" that precedes an element does not exclude the presence of a plurality of elements. The invention can be implemented by means of hardware comprising several different elements, and by means of a properly programmed computer.

In claiming the device that enumerates several means, several of these means can be formed by means of the same hardware article. The mere fact that certain measures are mentioned in mutually different dependent claims does not indicate that a combination of these measures can not be used to advantage. It is noted that in relation to this date, the best method known to the applicant to carry out the aforementioned invention, is that which is clear from the present description of the invention.

Claims (2)

CLAIMS Having described the invention as above, the content of the following claims is claimed as property: 1. A method for generating a list of authorization status, characterized in that it comprises generating a coded length-execution representation of an authorization status of an number of devices and store the representation in the authorization status list indicating, for each of a number of device ranges, the devices in a particular range that have the same authorization status, the number of devices in each of those .ranges. The method according to claim 1, characterized in that it comprises indicating in the list of authorization status each of the ranges the authorization status shared by the devices in each of those ranges. 3. The method according to claim 1 or 2, characterized in that it comprises indicating a limit of the ranges in the authorization status list. 4. The method according to claim 3, characterized in that it comprises indicating as limit a device identifier lower and / or higher in the ranges. 5. The method according to any of the preceding claims, characterized in that it comprises generating the representation indicating, for a first range of devices, the devices in the first rank that have the same first authorization status, the number of devices in the first rank, and, for a second range of devices, the devices in the second rank that have the same second authorization status, the number of devices in the second rank. 6. The method according to claim 5, characterized in that the second rank is successive to the first rank and the first authorization status differs from the second authorization status. The method according to claim 5, characterized in that it comprises omitting an additional range if the additional range is of a predetermined length. 8. The method according to claim 7, characterized by the predetermined length is equal to one. 9. The method according to claim 7, characterized in that it comprises indicating the predetermined length in the authorization status list. The method according to claim 1, characterized in that it comprises indicating in the authorization status list a number of bits used to indicate the number of devices in each of the ranges. 11. The method according to any of the preceding claims, characterized in that it comprises indicating in the list of authorization status a version number and / or a creation date. The method according to any one of the preceding claims, characterized in that it comprises transmitting the list of authorization status to a device to allow the device to verify the authorization status of itself or of an additional device. The method according to any of the preceding claims, characterized in that it comprises recording the list of authorization status in a storage medium. The method according to claim 13, characterized in that it comprises recording the list of authorization status in a fixed data area of a rewritable storage medium. The method according to claim 13, characterized in that it comprises recording the authorization status list in a rewritable area of a rewritable storage medium and recording a cryptographic summary of the authorization status list in a fixed data area of the rewritable storage medium. 16. A device characterized in that it is arranged to execute the method according to the claim

1. - 17. A computer program characterized in that it causes a processor to execute the method according to claim 1. 18. A source device arranged to authorize an operation by means of a sink device, characterized in that the source device comprises means for verifying the authorization status for verifying the authorization status of the sink device using a list of authorization status as it is produced in accordance with the method of claim 1. 19. A recording bearer in which a list of authorization status characterized in that it is produced by means of the method according to claim 1 is recorded. The recording bearer according to claim 19, characterized in that it comprises a fixed data area and an area of rewritable data, in which the list of authorization status in the fixed data area is recorded. The recording bearer according to claim 19, characterized in that it comprises a fixed data area and a rewritable data area, in which the list of authorization status is recorded in the rewritable area and a cryptographic summary of the list of authorization status is recorded in the fixed data area. 2

2. A signal characterized by representing a list of authorization status as produced by the method according to claim 1.