CERTIFICATE IMPLEMENTATION SYSTEM FIELD OF THE INVENTION

The present invention relates to public-key infrastructure (PKI) schemes which use certificates, to systems using such PKI schemes and certificates, and to systems using symmetric cryptography.

BACKGROUND OF THE INVENTION

Public-key infrastructure (PKI) schemes typically use a certificate authority structure which is typically hierarchical. A hierarchical certificate authority structure typically has several hierarchical layers starting from a root level, continuing with zero or more intermediate levels, and ending with a leaf level having the lowest level in the hierarchy.

A certificate in such a hierarchical certificate authority structure is typically signed by a private key corresponding to a public key in a higher level (parent) certificate and such a signing procedure continues in a chain until reaching a root certificate. A client (child) receiving such a certificate typically validates each signature along the chain in order to determine, indirectly, that a certifying secure entity, also known as a certificate authority (CA), is indeed certifying identity and policies along the chain to the client. Each certificate typically contains the following: (1) an identity of the client; (2) a public key; (3) (optionally) policies associated with a certifying secure entity; and (4) (optionally) an identity of the certifying secure entity. The policies typically define a security level such as high, medium or low. However, such policies may not be sufficient to identify and overcome security problems in highly secure systems and such policies also do not sufficiently relate to security problems in elements and sub-systems of the secure systems.

Some aspects of technologies and related material that may be useful in understanding the present invention are described in the following:

PCT patent application No. PCT/IL2005/000957 of NDS Limited, filed 8 September 2005, which describes a method and system for handling certificate renewals; and

A description at the world-wide-web (WWW) site www.svpalliance.org, which refers to secure video processors (SVPs).

The disclosures of all references mentioned above and throughout the specification, as well as the disclosures of all references mentioned in those references, are hereby incorporated herein by reference.

SUMMARY OF THE INVENTION

The present invention, in preferred embodiments thereof, seeks to provide a method and system for improving certificate handling and implementation in public-key infrastructure (PKI) schemes, for adding security features to such certificates, and for implementing, in appropriate cases, symmetric cryptography using symmetric certificates.

In preferred embodiments of the present invention, secure devices in a secure communication system exchange certificates which are usable to permit communication between communication appliances comprising the secure devices or associated with the secure devices. Each certificate preferably has, in addition to a certificate field comprising an indication of identity of a secure device to which the certificate pertains and a certificate field comprising a public key, one or more certificate fields comprising additional information which is used to determine security levels and other security parameters of various elements in the secure devices and / or in the secure communication system.

The one or more certificate fields comprising additional information preferably comprise at least one of the following certificate fields: a certificate field comprising a level of security of a timer used in the secure communication system; a certificate field comprising a level of security of a non- volatile memory (NVM) of the secure device to which the certificate pertains; a certificate field comprising a level of implementation of export to another secure communication system; a certificate field comprising an identification of at least one encryption mode supported by the secure device to which the certificate pertains; and a certificate field comprising a rendering type specification. Secure communication among the secure devices may be implemented using symmetric cryptography between each pair of the secure devices. The symmetric cryptography preferably uses shared symmetric keys and symmetric certificates.

The term "symmetric certificate" is used throughout the specification and claims to refer to a certificate which is associated with at least one symmetric secret key, that is, the certificate may: include a symmetric secret key and be signed by a symmetric signing secret key; or include a symmetric

secret key and be signed by an asymmetric signing private key; or include an asymmetric public key and be signed by a symmetric signing secret key.

There is thus provided in accordance with a preferred embodiment of the present invention a certificate for use in a secure communication system that employs a public-key infrastructure (PKI) scheme, the certificate including a certificate field including an indication of identity of a secure device to which the certificate pertains, a certificate field including a public key, and at least one of the following certificate fields: a certificate field including a level of security of a timer used in the secure communication system, a certificate field including a level of security of a non- volatile memory (NVM) of the secure device, a certificate field including a level of implementation of export to another secure communication system, a certificate field including an identification of at least one encryption mode supported by the secure device, and a certificate field including a rendering type specification. Preferably, the certificate field including an identification of at least one encryption mode supported by the secure device includes an identification of at least one of the following: a cryptographic algorithm type, and a chaining mode.

The chaining mode preferably includes one of the following: Electronic Codebook (ECB) mode, Cipher Block Chaining (CBC) mode, Cipher Feedback (CFB) mode, and Output Feedback (OFB) mode.

Preferably, each of the following includes a level in an ascending scale: the level of security of the timer, the level of security of the NVM, and the level of implementation of export to another secure communication system.

The ascending scale preferably includes a 16-level ascending scale implemented in 4 bits.

Preferably, each of a secure device and a certifying secure entity comprises the certificate.

There is also provided in accordance with a preferred embodiment of the present invention a secure communication system that employs a public-key infrastructure (PKI) scheme, the system including first and second secure devices, and a certificate usable for obtaining security permission permitting the first secure device and the second secure device to communicate with each other, the

certificate including a certificate field including an indication of identity of one of the first and second secure devices to which the certificate pertains, a certificate field including a public key, and at least one of the following certificate fields: a certificate field including a level of security of a timer used in the secure communication system, a certificate field including a level of security of an NVM of the one of the first and second secure devices to which the certificate pertains, a certificate field including a level of implementation of export to another secure communication system, a certificate field including an identification of at least one encryption mode supported by the one of the first and second secure devices to which the certificate pertains, and a certificate field including a rendering type specification.

Further in accordance with a preferred embodiment of the present invention there is provided a secure communication method for use with a secure communication system that employs a public-key infrastructure (PKI) scheme, the method including providing first and second secure devices, and using a certificate for obtaining security permission permitting the first and second secure devices to communicate with each other, the certificate including a certificate field including an indication of identity of one of the first and second secure devices to which the certificate pertains, a certificate field including a public key, and at least one of the following certificate fields: a certificate field including a level of security of a timer used in the secure communication system, a certificate field including a level of security of an NVM of the one of the first and second secure devices to which the certificate pertains, a certificate field including a level of implementation of export to another secure communication system, a certificate field including an identification of at least one encryption mode supported by the one of the first and second secure devices to which the certificate pertains, and a certificate field including a rendering type specification.

Still further in accordance with a preferred embodiment of the present invention there is provided a secure communication method for use with a first secure device communicating in a secure communication system that employs a public-key infrastructure (PKI) scheme, the method including receiving, from a certifying secure entity in the secure communication system, a certificate which

includes the following certificate fields: a certificate field including an indication of identity of a second secure device, a certificate field including a public key, and at least one of the following certificate fields: a certificate field including a level of security of a timer used in the secure communication system, a certificate field including a level of security of an NVM of the second secure device, a certificate field including a level of implementation of export to another secure communication system, a certificate field including an identification of at least one encryption mode supported by the second secure device, and a certificate field including a rendering type specification, validating the certificate to obtain security permission, and enabling exchange of content between a first communication appliance associated with the first secure device and a second communication appliance associated with the second secure device in accordance with the security permission.

Preferably, the validating includes checking the certificate in response to receipt of a content license accompanied by an unsigned request from at least one of the following: a set-top box (STB), and an SVP manager.

Alternatively or additionally, the content may include a content license, and the security permission may include permission to use the content.

Additionally, the method also includes, prior to the receiving, signing the certificate with a private key.

Preferably, the secure communication system includes a secure television delivery system, and the certifying secure entity includes a headend in the secure television delivery system.

There is also provided in accordance with a preferred embodiment of the present invention a method of enabling communication among secure devices in a secure system which includes a trusted entity that is capable of transmitting secure messages to each of the secure devices, the method including providing a pair of the secure devices with a shared symmetric key, and implementing symmetric cryptography in communication between the secure devices in the pair using the shared symmetric key.

Preferably, the implementing includes issuing, by the trusted entity, a pair of symmetric certificates for the pair of the secure devices, the symmetric

certificates being usable to permit communication between the secure devices in the pair of the secure devices in accordance with security permission defined by the trusted entity.

The pair of symmetric certificates preferably includes a first symmetric certificate for use by a first secure device in the pair of the secure devices in communication with a second secure device in the pair of the secure devices, and a second symmetric certificate for use by the second secure device in communication with the first secure device.

Preferably, the first symmetric certificate includes the following certificate fields: a certificate field including an indication of identity of the second secure device, a certificate field including the shared symmetric key in an encrypted form, and at least one of the following certificate fields: a certificate field including a level of security of a timer used in the secure system, a certificate field including a level of security of an NVM of the second secure device, a certificate field including a level of implementation of export to another secure system, a certificate field including an identification of at least one encryption mode supported by the second secure device, and a certificate field including a rendering type specification.

The second symmetric certificate preferably includes the following certificate fields: a certificate field including an indication of identity of the first secure device, a certificate field including the shared symmetric key in an encrypted form, and at least one of the following certificate fields: a certificate field including a level of security of a timer used in the secure system, a certificate field including a level of security of an NVM of the first secure device, a certificate field including a ievel of implementation of export to another secure system, a certificate field including an identification of at least one encryption mode supported by the first secure device, and a certificate field including a rendering type specification.

Preferably, each of the first symmetric certificate and the second symmetric certificate is signed with a symmetric secret signing key.

The symmetric secret signing key preferably includes one of the following: a key by which the shared symmetric key is encrypted, and a key other than the key by which the shared symmetric key is encrypted.

Preferably, the secure system includes a secure television delivery system, and the trusted entity includes a headend in the secure television delivery system.

The issuing preferably includes obtaining, for each of the first secure device and the second secure device, information usable for defining security permission, selecting a shared key SK, obtaining a secret key KA for the first secure device, and a secret key KB for the second secure device, signing the following using KB in order to produce the second symmetric certificate: SK, an indication of identity of the first secure device, and the information usable for defining security permission which pertains to the first secure device, encrypting the second symmetric certificate using KB, signing the following using KA in order to produce the first symmetric certificate: SK, an indication of identity of the second secure device, and the information usable for defining security permission which pertains to the second secure device, and encrypting the first symmetric certificate using KA.

Preferably, each of the secret keys KA and KB includes one of the following: a symmetric key, and an asymmetric private key.

The shared key SK preferably includes one of the following: a shared symmetric key, and a public key.

Also in accordance with a preferred embodiment of the present invention there is provided a secure system including a pair of secure devices, and a trusted entity that is capable of transmitting secure messages to each of the secure devices in the pair and is operative to provide the pair of secure devices with a shared symmetric key, wherein the secure devices in the pair communicate with each other by implementing symmetric cryptography using the shared symmetric key. Further in accordance with a preferred embodiment of the present invention there is provided a secure device including a receiving interface receiving a certificate including a shared symmetric key, and a processor

permitting the secure device to communicate with another secure device by implementing symmetric cryptography using the shared symmetric key.

BRIEF DESCRIPTION OF THE DRAWINGS

The present invention will be understood and appreciated more fully from the following detailed description, taken in conjunction with the drawings in which: Fig. 1 is a simplified partly pictorial, partly block diagram illustration of a secure communication system constructed and operative in accordance with a preferred embodiment of the present invention;

Fig. 2 is a simplified pictorial illustration of a preferred embodiment of a certificate usable in the secure communication system of Fig. 1; Fig. 3 is a simplified partly pictorial, partly block diagram illustration of a secure system constructed and operative in accordance with another preferred embodiment of the present invention;

Fig. 4 is a simplified flowchart illustration of a preferred method of operation of the system of Fig. 1; Fig. 5 is a simplified flowchart illustration of a preferred method of operation of a secure device in either the system of Fig. 1 or the system of Fig. 3; and

Fig. 6 is a simplified flowchart illustration of a preferred method of operation of the system of Fig. 3.

DETAILED DESCRIPTION OF A PREFERRED EMBODIMENT

Reference is now made to Fig. 1, which is a simplified partly pictorial, partly block diagram illustration of a secure communication system 10 constructed and operative in accordance with a preferred embodiment of the present invention.

The system 10 preferably employs a public-key infrastructure (PKI) scheme as is well known in the art. Preferably, the system 10 includes a certifying secure entity 20 and a multiplicity of secure devices 30. The certifying secure entity 20 and the secure devices 30 preferably communicate via a two-way communication network 40.

The communication network 40 may preferably comprise at least one of the following (all not shown): a satellite based communication network; a cable based communication network; a terrestrial broadcast based television network; a telephony based television delivery network; a mobile-telephony based television delivery network; a mobile-telephony based communication network; an Internet Protocol (IP) based television delivery network; and a computer-based communication network. Persons skilled in the art will appreciate that any appropriate communication network may be used.

One non-limiting example of an appropriate telephony or IP based television delivery network is the Synamedia™ system, commercially available from NDS Limited, One Heathrow Boulevard, 286 Bath Road, West Drayton, Middlesex UB7 ODQ, United Kingdom.

It is appreciated that the communication network 40 may, for example, be implemented by a two-way hybrid communication network, such as a combination cable-telephone network, a combination satellite-telephone network, a combination terrestrial broadcast-telephone network, a combination satellite-computer based communication network, or by any other appropriate two-way hybrid or non-hybrid network.

Physical links in the communication network 40 may be implemented via optical links, conventional telephone links, radio frequency (RF) wired or wireless links, or any other appropriate links.

The certifying secure entity 20 may be an independent entity connected to the communication network 40 or may be comprised in another entity that communicates via the communication network 40. For example, which is not meant to be limiting, in a case where the system 10 delivers television programming as well as other information and the communication network 40 comprises a television delivery network, the certifying secure entity 20 may comprise or be comprised in a headend (not shown).

It is appreciated that the television programming and the other information may preferably comprise at least one of the following: pay and/or non-pay television programming; multimedia information; audio programs; data; games; and information from computer based networks such as the Internet. Online access to information and web content from the Internet may, by way of a non-limiting example, be provided by the XSPACE software solution, commercially available from NDS Limited, One Heathrow Boulevard, 286 Bath Road, West Drayton, Middlesex UB7 ODQ, United Kingdom.

Each of the secure devices 30 is preferably comprised in a communication appliance 50, which is preferably comprised in the system 10. Alternatively, each of the secure devices 30 may be operatively associated with such a communication appliance 50, and the communication appliance 50 may be comprised in the system 10 or operatively associated with the system 10.

In the case where the system 10 delivers television programming and information and the communication network 40 comprises a television delivery network, the communication appliance 50 may, by way of a non-limiting example, comprise a set-top box (STB) which is conventionally used in television systems. In such a case, each of the secure devices 30 may preferably comprise at least one of the following: a secure video processor (SVP); and a smart card (both not shown).

In a further non-limiting example, in a case where the communication network 40 comprises a mobile-telephony based communication network, the communication appliance 50 may comprise a cellular telephone and each secure device 30 may be comprised in such a cellular telephone. In a case where the communication network 40 comprises a computer-based

communication network, each secure device 30 may be comprised in or operatively associated with a communication appliance 50 comprising a computing device such as a personal computer (PC) or a personal digital assistant (PDA) having a communication interface. Preferably, regardless of a type of the communication appliance 50 in which each secure device 30 is comprised or with which each secure device 30 is operatively associated, each secure device 30 enables the communication appliance 50 operatively associated therewith to conditionally access content communicated by the communication network 40. The content communicated by the communication network 40 may, for example, be provided by various content providers and communicated in accordance with content licenses issued by the content providers, or by the certifying secure entity 20 in accordance with instructions of the content providers, or by third parties authorized by the content providers to issue content licenses. The content providers may include providers of any appropriate type of content and data which is communicated via the communication network 40. A non-limiting example of a content provider comprises the headend or a content provider which provides information and content services via the headend. Other non-limiting examples of content providers comprise Internet service providers (ISPs) and web sites which provide information.

Preferably, in order to enable communication of the content among the communication appliances 50, the secure devices 30 communicate with the certifying secure entity 20 and among themselves via the communication network 40 in accordance with security permissions defined by the certifying secure entity 20. The security permissions are preferably defined by the certifying secure entity 20 in certificates 60 which are preferably issued by the certifying secure entity 20. The certificates 60 are preferably communicated between the certifying secure entity 20 and the secure devices 30 and among the secure devices 30 in cases where the secure devices 30 communicate among themselves. Each secure device 30 preferably stores a certificate 60 pertaining thereto in a memory (not shown), such as a non-volatile memory (NVM), which is comprised in the secure device 30; when two secure devices 30 communicate, the secure devices 30 preferably

exchange their certificates 60 and each secure device 30 preferably processes, checks and validates the certificate 60 received from the other secure device 30.

Communication between the certifying secure entity 20 and the secure devices 30 and among the secure devices 30 may, by way of a non-limiting example, be based on a hierarchical certificate authority structure which has a chain of several hierarchical layers starting from a root level, continuing with zero or more intermediate levels, and ending with a leaf level having the lowest level in the hierarchy.

In such hierarchical certificate authority structure based communication, each of the certificates 60 includes a chain of certificates. A first secure device 30 that communicates with a second secure device 30 receives the certificate 60 of the second secure device 30 and processes the received certificate 60 to validate each signature along the chain in order to determine, indirectly, that the certificate 60 of the second secure device 30 is valid. Similarly, the second secure device 30 receives the certificate 60 of the first secure device 30 and processes the received certificate 60 to validate each signature along the chain in order to determine, indirectly, that the certificate 60 of the first secure device 30 is valid.

Reference is now additionally made to Fig. 2, which is a simplified pictorial illustration of a preferred embodiment of the certificate 60 usable in the secure communication system 10 of Fig. 1.

Preferably, the certificate 60 comprises the following certificate fields: a certificate field 100 comprising an indication of identity of a secure device 30 to which the certificate 60 pertains; a certificate field 110 comprising a public key; and at least one of the following certificate fields: a certificate field 120 comprising a level of security of a timer (not shown) used in the secure communication system 10; a certificate field 130 comprising a level of security of a non- volatile memory (NVM) (not shown) of the secure device 30 to which the certificate 60 pertains; a certificate field 140 comprising a level of implementation of export to another secure communication system (not shown); a certificate field 150 comprising an identification of at least one encryption mode supported by the

secure device 30 to which the certificate 60 pertains; and a certificate field 160 comprising a rendering type specification.

The level of security of the timer preferably indicates an extent to which the timer is secure, the level of security of the NVM preferably indicates an extent to which the NVM is secure, and the level of implementation of export to another secure communication system preferably indicates an extent to which implementation of export to another secure communication system is secure. Each of the level of security of the timer, the level of security of the NVM and the level of implementation of export to another secure communication system may include one of, for example, 16 levels ranging from the lowest level of security to the highest level of security. For example, level "0" may represent the lowest security level, level "15" may represent the highest security level, and any level between "0" and "15" may represent a security level which is higher than the lowest security level and lower than the highest security level. The 16 levels are preferably arranged such that a difference between two levels expresses a corresponding difference in security.

It is appreciated that the number of levels may alternatively be different than 16, and any other appropriate number of levels may alternatively be implemented. Additionally, the levels may be arranged in any other appropriate arrangement, such as, for example, an arrangement in which level "0" represents the highest security level and level "15" represents the lowest security level.

The rendering type specification specifies various parameters which refer to a rendering device, which rendering device may, for example, include a television or a computer monitor (both not shown) used for rendering content communicated by the communication network 40. For example, the rendering type specification may specify whether the television is a high-definition television or a regular television, a number of pixels used for rendering, bit-rate of audio played, etc.

The certificate field 100 may, for example, comprise a digital code representation which identifies the secure device 30 to which the certificate 60 pertains. The digital code representation comprises, by way of a non-limiting

example, a 64-bit code representation, but it appreciated that the certificate field 100 may alternatively be implemented in any other appropriate number of bits.

The certificate field 110 comprises a public key as is well known in the art and the number of bits in the certificate field 110 corresponds to a public key length. For example, for a typical 1024-bit public key the certificate field 110 is implemented in 1024 bits, and for a typical 2048-bit public key the certificate field 110 is implemented in 2048 bits. It is appreciated that public keys having other lengths may alternatively be used, in which case the certificate field 110 is implemented in a corresponding number of bits. The timer whose level of security is comprised in the certificate field 120 may preferably comprise a timer used in the system 10 for cryptographic applications, such as a secure timer. By way of a non-limiting example, the certificate field 120 may be implemented in 4 bits, but it is appreciated that the certificate field 120 may alternatively be implemented in any other appropriate number of bits.

The NVM whose level of security is comprised in the certificate field 130 preferably comprises any appropriate NVM of the secure device 30, such as, by way of a non-limiting example, an Electrically-Erasable Programmable Read-Only Memory (EEPROM). By way of a non-limiting example, the certificate field 130 may be implemented in 4 bits, but it is appreciated that the certificate field 130 may alternatively be implemented in any other appropriate number of bits.

The level of implementation of export to another secure communication system in the certificate field 140 is preferably applicable in a case where the certifying secure entity 20 and / or any of the secure devices 30 communicate with another secure communication system (not shown) which may, by way of a non-limiting example, have different security policies. By way of a non-limiting example, the certificate field 140 may be implemented in 4 bits, but it is appreciated that the certificate field 140 may alternatively be implemented in any other appropriate number of bits.

Each of the level of security of the timer, the level of security of the NVM, and the level of implementation of export to another secure communication

system may, by way of a non-limiting example, be implemented in an ascending scale, such as a 16-level ascending scale implemented in 4 bits, but it is appreciated that any other appropriate scale implemented in any other appropriate number of bits may alternatively be used. The certificate field 150 preferably comprises an identification of at least one of the following: a cryptographic algorithm type; and a chaining mode. The cryptographic algorithm type may, for example, include any appropriate scrambling or encryption scheme, such as, for example, DES (Data Encryption Standard), AES (Advanced Encryption Standard), or triple-DES. The chaining mode preferably refers to each block-cipher and comprises, for example, one of the following: Electronic Codebook (ECB) mode; Cipher Block Chaining (CBC) mode; Cipher Feedback (CFB) mode; and Output Feedback (OFB) mode.

By way of a non-limiting example, the certificate field 150 may comprise a bitmap implemented in 16 bits, but it appreciated that the bitmap of the certificate field 150 may alternatively be implemented in any other appropriate number of bits.

Preferably, the bitmap of the certificate field 150 represents either encryption modes which include cryptographic algorithm types only, or encryption modes which include both cryptographic algorithm types and chaining modes. In a case where the bitmap of the certificate field 150 represents encryption modes which include cryptographic algorithm types only, each bit in the bitmap of the certificate field 150 preferably represents a specific cryptographic algorithm type. For example, which is not meant to be limiting, a first bit in the bitmap of the certificate field 150 may represent DES, a second bit in the bitmap of the certificate field 150 may represent AES, a third bit in the bitmap of the certificate field 150 may represent triple-DES, etc.

In a case where the bitmap of the certificate field 150 represents encryption modes which include both cryptographic algorithm types and chaining modes, each bit in the bitmap of the certificate field 150 preferably represents a combination of a cryptographic algorithm type and a chaining mode. For example, which is not meant to be limiting, a first bit in the bitmap of the certificate field 150 may represent a combination of DES with ECB mode chaining, a second bit in

the bitmap of the certificate field 150 may represent a combination of DES with CBC mode chaining, a third bit in the bitmap of the certificate field 150 may represent a combination of AES with ECB mode chaining, etc.

It is appreciated that in many cases decryption modes are identical to the encryption modes, that is identical cryptographic algorithm types and chaining modes are used for encryption and decryption. However, in cases where there are decryption modes which are different from the encryption modes some of the bits of the bitmap of the certificate field 150 may represent the different decryption modes. The different decryption modes may include either decryption modes which include cryptographic algorithm types only, or decryption modes which include both cryptographic algorithm types and chaining modes.

Preferably, when a bit in the bitmap of the certificate field 150 has a value of "1", an encryption mode represented by the bit is supported by the secure device 30 to which the certificate 60 pertains. When a bit in the bitmap of the certificate field 150 has a value of "0", an encryption mode represented by the bit is not supported by the secure device 30 to which the certificate 60 pertains. Alternatively, the value "1" of a bit may indicate that an encryption mode is not supported and the value "0" of a bit may indicate that an encryption mode is supported. The bitmap of the certificate field 150 may, for example, indicate that more than one encryption mode is supported by the secure device 30 to which the certificate 60 pertains, such as, for example, three encryption modes. In such a case, three separate bits in the bitmap of the certificate field 150 have the value of "1". It is appreciated that each bit in the bitmap of the certificate field 150 may be referred to using a value represented by a 4-bit combination.

The certificate field 160 preferably includes a representation of one parameter or more than one parameter which represents the rendering type specification. By way of a non-limiting example, the certificate field 160 may comprise a bitmap implemented in 64 bits, but it appreciated that the bitmap of the certificate field 160 may alternatively be implemented in any other appropriate number of bits.

Preferably, the bitmap of the certificate field 160 represents either one rendering type parameter or more than one rendering type parameter. In a case where the bitmap of the certificate field 160 represents only one rendering type parameter, each bit in the bitmap of the certificate field 160 preferably represents a specific rendering type parameter. For example, which is not meant to be limiting, a first bit in the bitmap of the certificate field 160 may specify a high-definition television, a second bit in the bitmap of the certificate field 160 may specify a regular television, a third bit in the bitmap of the certificate field 160 may specify a specific bit-rate of audio played, etc. In a case where the bitmap of the certificate field 160 represents more than one rendering type parameter, each bit in the bitmap of the certificate field 160 preferably represents a specific combination of rendering type parameters. For example, which is not meant to be limiting, a first bit in the bitmap of the certificate field 160 may specify a high-definition television and a specific bit-rate of audio played, a second bit in the bitmap of the certificate field 160 may specify a regular television and a specific bit-rate of audio played, etc.

Preferably, when a bit in the bitmap of the certificate field 160 has a value of "1", a rendering type specification represented by the bit is supported by the system 10 and / or by secure device 30 to which the certificate 60 pertains. When a bit in the bitmap of the certificate field 160 has a value of "0", a rendering type specification represented by the bit is not supported by the system 10 and / or by the secure device 30 to which the certificate 60 pertains. Alternatively, the value "1" of a bit may indicate that a rendering type specification is not supported and the value "0" of a bit may indicate that a rendering type specification is supported.

The bitmap of the certificate field 160 may, for example, indicate that more than one rendering type specification is supported by the system 10 and / or by the secure device 30 to which the certificate 60 pertains, such as, for example, five rendering type specifications. In such a case, five separate bits in the bitmap of the certificate field 160 have the value of "1". It is appreciated that each bit in the bitmap of the certificate field 160 may be referred to using a value represented by a 6-bit combination.

It is further appreciated that the certificate 60 may include additional fields (not shown), and information which determines and certifies various types of security policies, such as a bandwidth policy as described in the above-mentioned PCT patent application No. PCT/IL2005/000957, filed 8 September 2005, the disclosure of which has been incorporated herein by reference.

By way of a non-limiting example, the certificate 60 shown in Fig. 2 is depicted including all the fields 120, 130, 140, 150 and 160, but it is appreciated that the certificate 60 may include less than all the fields 120, 130, 140, 150 and 160, such as, for example, only one of the fields 120, 130, 140, 150 and 160. Further by way of a non-limiting example, in Fig. 2 the field 100 is implemented in 64 bits, the field 110 is implemented in 1024 bits, each of the fields 120, 130 and 140 is implemented in 4 bits, the field 150 is implemented in a 16-bit bitmap, and the field 160 is implemented in a 64-bit bitmap. In operation, the certifying secure entity 20 issues the certificates

60, signs the certificates 60 with a private key, and transmits the signed certificates 60 to the secure devices 30. Each certificate 60 is issued with levels and values in the certificate fields 100, 110, 120, 130, 150, 150 and 160 which pertain to a secure device 30 for which the certificate 60 is intended. It is appreciated that each secure device 30 may optionally validate its own certificate 60 which is received from the certifying secure entity 20.

In order to prepare a first communication appliance 50 which is associated with a first secure device 30 and a second communication appliance 50 which is associated with a second secure device 30 for exchanging content, a first certificate 60 which pertains to the first secure device 30 is communicated from the first secure device 30 to the second secure device 30, and a second certificate 60 which pertains to the second secure device 30 is communicated from the second secure device 30 to the first secure device 30.

In a hierarchical certificate authority structure each of the first and second certificates 60 typically includes a chain of certificates. The first secure device 30 preferably validates the second certificate 60 which is received from the second secure device 30 by using a signature checking procedure which starts with

a known root public key and operates to obtain public keys along a chain to the second secure device 30 and to check each signature along the chain with an obtained public key in a higher hierarchical level in order to determine, indirectly, authenticity of the certifying secure entity 20 and the identity of the second secure device 30. Similarly, the second secure device 30 preferably validates the first certificate 60 which is received from the first secure device 30 by using a signature checking procedure which starts with the known root public key and operates to obtain public keys along a chain to the first secure device 30 and to check each signature along the chain with an obtained public key in a higher hierarchical level in order to determine, indirectly, authenticity of the certifying secure entity 20 and the identity of the first secure device 30.

After exchanging their certificates 60, the first secure device 30 and the second secure device 30 typically obtain a content license from a content provider or from a third party authorized directly or indirectly by the content provider to provide the content license. The content license preferably includes security levels and parameter values to be checked against security levels and parameter values in at least one of the first certificate 60 and the second certificate 60 in order to determine whether security permission may be obtained.

It is appreciated that in a typical case checking of the security levels and parameter values in the content license is to be performed against the security levels and parameter values in both the first certificate 60 and the second certificate 60. However, in certain cases it is sufficient to check the security levels and parameter values in the content license against the security levels and parameter values in only one of the first certificate 60 and the second certificate 60, such as the one of the first certificate 60 and the second certificate 60 which is intended for the one of the first communication appliance 50 and the second communication appliance 50 that is to receive or to download the content.

Preferably, the first secure device 30 checks levels in the certificate fields 120, 130 and 140 of the second certificate 60 against respective security levels in the content license. Additionally, in a case where the first secure device 30 is instructed, for example by a software application in the first communication appliance 50, to perform decryption, the first secure device 30 preferably checks

values in the certificate field 150 of its own certificate 60 against a corresponding value in the content license, and in a case where the first secure device 30 is instructed, for example by a software application in the first communication appliance 50, to perform encryption, the first secure device 30 preferably checks values in the certificate field 150 of its own certificate 60 against a corresponding value in an unsigned request that accompanies the content license. The first secure device 30 also preferably checks values in the certificate field 160 of its own certificate 60 against a corresponding value in the unsigned request.

Similarly, the second secure device 30 preferably checks levels in the certificate fields 120, 130 and 140 of the first certificate 60 against respective security levels in the content license. Additionally, in a case where the second secure device 30 is instructed, for example by a software application in the second communication appliance 50, to perform decryption, the second secure device 30 preferably checks values in the certificate field 150 of its own certificate 60 against a corresponding value in the content license, and in a case where the second secure device 30 is instructed, for example by a software application in the second communication appliance 50, to perform encryption, the second secure device 30 preferably checks values in the certificate field 150 of its own certificate 60 against a corresponding value in an unsigned request that accompanies the content license. The second secure device 30 also preferably checks values in the certificate field 160 of its own certificate 60 against a corresponding value in the unsigned request.

If authenticity of the certifying secure entity 20 and the identities of each of the first and second secure devices 30 are confirmed and checking of the levels and values in the certificate fields 120, 130, 140, 150 and 160 of the first and second certificates 60 against the respective security levels and parameter values in the content license and in the unsigned request determines that security permission may be obtained, an indication of security permission is issued. Once the indication of security permission is issued, the first communication appliance 50 and the second communication appliance 50 preferably exchange the content in accordance with the security permission.

The security levels in the content license preferably include levels corresponding to the levels in the certificate fields 120, 130 and 140. If not all the fields 120, 130 and 140 are used in the first and second certificates 60 then the security levels in the content license preferably include security levels corresponding only to levels in those of the fields 120, 130 and 140 that are used in the first and second certificates 60. Also, the content license may include a value corresponding to a value in the certificate field 150 for use in case of decryption and the unsigned request may include a value corresponding to a value in the certificate field 150 for use in case of encryption. The unsigned request may also include a value for use in a case where a rendering type is specified, and if the field 160 in the first and second certificates 60 is used, the rendering type may be checked against values in the field 160 of the first and second certificates 60.

By way of a non-limiting example, all the fields 120, 130, 140, 150 and 160 are used in the first and second certificates 60, an encryption operation is to be performed, the unsigned request includes a parameter value for identification of an encryption mode of the content and a parameter value for a rendering type specification and the content license includes security levels for the following: the level of security of the timer; the level of security of the NVM; and the level of implementation of export to another secure communication system. In such a case, the unsigned request may include a 4-bit combination representing, for example, DES as the encryption mode of the content and a 6-bit combination representing, for example, a rendering type parameter suitable for a high-definition television as the rendering type specification, and the content license may, by way of a non-limiting example, include: a representation of the value "15" for the level of security of the timer; a representation of the value "14" for the level of security of the NVM; and a representation of the value "5" for the level of implementation of export to another secure communication system.

In the example in which each of the level of security of the timer, the level of security of the NVM, and the level of implementation of export to another secure communication system is implemented in a 16-level ascending scale, the values "15" and "14" for the level of security of the timer and the level of security of the NVM imply that the timer and the NVM are highly secure and

the value "5" for the level of implementation of export to another secure communication system implies that export to another secure communication system is not particularly secure. If export to another secure communication system is considered as not particularly secure, then such export to another secure communication system may be forbidden, or at least a warning message may be issued when an attempt is made to perform export to another secure communication system.

It is appreciated that in a different scale the above values for the level of security of the timer, the level of security of the NVM, and the level of implementation of export to another secure communication system may have other meanings.

Preferably, if authenticity of the certifying secure entity 20 and the identities of each of the first and second secure devices 30 are confirmed and, for example, the security levels in the certificate fields 120, 130 and 140 of each of the first certificate 60 and the second certificate 60 match the above-mentioned security levels in the content license, and the parameter values in the content license and in the unsigned request refer to an encryption mode and a rendering type specification supported by the first secure device 30 and the second secure device 30, then at least one of the first secure device 30 and the second secure device 30 preferably issues an indication of security permission. The first communication appliance 50 and the second communication appliance 50 are then preferably allowed to exchange the content in accordance with the security permission.

In the case where the system 10 delivers television programming and information and the communication network 40 comprises a television delivery network, the certifying secure entity 20 may preferably comprise a headend (not shown), at least one of the first communication appliance 50 and the second communication appliance 50 may preferably comprise an STB (not shown), and at least one of the first secure device 30 and the second secure device 30 may preferably comprise at least one of the following: an SVP; and a smart card (both not shown). In such a case, checking of each certificate 60 preferably comprises checking the certificate 60 in response to receipt of the content license

accompanied by the unsigned request from at least one of the following: the STB; and an SVP manager (not shown) which is preferably comprised in software residing in the STB. Also, the content exchanged between the first communication appliance 50 and the second communication appliance 50 preferably comprises the content license, and the security permission preferably comprises permission to use the content.

It is appreciated that various sub-combinations of the secure communication system 10 may comprise alternative preferred embodiments of the present invention. For example, and without limiting the generality of the foregoing, each of the following may comprise an alternative preferred embodiment of the present invention: any one of the secure devices 30; the certifying secure entity 20; and any one of the certificates 60.

Reference is now made to Fig. 3, which is a simplified partly pictorial, partly block diagram illustration of a secure system 200 constructed and operative in accordance with another preferred embodiment of the present invention.

The system 200 is preferably similar to the system 10 of Fig. 1, except that the system 200 preferably enables implementation of symmetric cryptography. The system 200 preferably includes a trusted entity 210 and a multiplicity of secure devices 220, the trusted entity 210 and the secure devices

220 preferably communicating via a two-way communication network 230, which may be similar in structure and function to the communication network 40 of Fig.

1. By way of a non-limiting example, the secure system 200 may comprise a secure television delivery system, and the trusted entity 210 may comprise a headend (not shown) in the secure television delivery system.

Similarly to the certifying secure entity 20 of Fig. 1, the trusted entity 210 may be an independent entity connected to the communication network 230 or may be comprised in another entity that communicates via the communication network 230. The secure devices 220 are preferably similar to the secure devices 30 and are similarly comprised in communication appliances 240, which are preferably comprised in the system 200. The secure devices 220 may alternatively be operatively associated with the communication appliances 240, in

which case the communication appliances 240 may be comprised in the system 200 or operatively associated with the system 200.

In the case where the secure system 200 comprises a secure television delivery system and the trusted entity 210 comprises a headend, at least one of the communication appliances 240 may, by way of a non-limiting example, comprise an STB (not shown) and at least one of the secure devices 220 may, for example, comprise at least one of the following: an SVP; and a smart card (both not shown).

Preferably, communication in the system 200 is enabled only between secure devices 220 in a pair and by implementing symmetric cryptography, such as DES or AES. The trusted entity 210 is preferably capable of transmitting secure messages to each of the secure devices 220 and capable of determining pairs of the secure devices 220 for which communication between pair members is to be permitted. Implementation of symmetric cryptography preferably comprises issuing, by the trusted entity 210, a pair of symmetric certificates for each pair of secure devices 220 for which communication between pair members is to be permitted. The symmetric certificates are preferably usable to permit communication between the secure devices 220 in each such pair of secure devices 220 and between communication appliances 240 associated with the secure devices 220 in each such pair of secure devices 220 in accordance with security permission defined by the trusted entity 210.

Preferably, the pair of symmetric certificates comprises a first symmetric certificate for use by a first secure device 220 in a pair of secure devices 220 in communication with a second secure device 220 in the pair of secure devices 220, and a second symmetric certificate for use by the second secure device 220 in communication with the first secure device 220.

Each of the first symmetric certificate and the second symmetric certificate preferably comprises certificate fields similar to the certificate fields 100, 110, 120, 130, 140, 150 and 160 of the certificate- 60 of Figs. 1 and 2, except that a shared symmetric key in an encrypted form replaces the public key in the

certificate field 110 of the certificate 60 of Figs. 1 and 2 for each of the first and second symmetric certificates.

In order to issue the pair of symmetric certificates, the trusted entity 210 preferably obtains, for each of the first secure device 220 and the second secure device 220, information usable for defining security permission. Such information preferably comprises information for insertion into the certificate fields of the symmetric certificates which correspond to the certificate fields 120, 130, 140, 150 and 160 of Fig. 2, which information comprises at least one of the following: a level of security of a timer (not shown) used in the secure system 200; levels of security of NVMs (not shown) of the first secure device 220 and the second secure device 220; a level of implementation of export to another secure system (not shown); an identification of at least one encryption mode supported by the first and second secure devices 220; and a rendering type specification.

After the trusted entity 210 obtains such information, the trusted entity 210 preferably selects a shared key SK and obtains a secret key KA for the first secure device 220, and a secret key KB for the second secure device 220. The secret key KA is preferably known only to the trusted entity 210 and to the first secure device 220, and the secret key KB is preferably known only to the trusted entity 210 and to the second secure device 220. The trusted entity 210 may select SK, for example, by using a random selection process. Alternatively, the trusted entity 210 may create the shared key SK by applying a keyed one-way function to identity representations of the first secure device 220 and the second secure device 220.

The trusted entity 210 then preferably signs the following using KA in order to produce the first symmetric certificate: SK; an indication of identity of the second secure device 220; and the information usable for defining security permission which pertains to the second secure device 220. The trusted entity 210 then preferably encrypts the first symmetric certificate with KA, and transmits the encrypted first symmetric certificate to the first secure device 220. Similarly, the trusted entity 210 preferably signs the following using

KB in order to produce the second symmetric certificate: SK; an indication of identity of the first secure device 220; and the information usable for defining

security permission which pertains to the first secure device 220. The trusted entity 210 then preferably encrypts the second symmetric certificate with KB, and transmits the encrypted second symmetric _. certificate to the second secure device 220. It is appreciated that the trusted entity 210 may alternatively encrypt the shared key SK before signing SK to produce each of the first and second symmetric certificates.

Each of the first and second secure devices 220 preferably receives the corresponding encrypted symmetric certificate at a receiving interface (not shown), and processes, decrypts and verifies the received encrypted symmetric certificate at a processor (not shown). The symmetric certificates are then preferably used by the processors of the first and second secure devices 220 to permit communication between the first secure device 220 and the second secure device 220 and between the communication appliances 240 associated with the first and second secure devices 220 in accordance with the security permission defined by the trusted entity 210.

It is appreciated that each of the secret keys KA and KB may preferably comprise one of the following: a symmetric key; and an asymmetric private key. The shared key SK preferably comprises one of the following: a shared symmetric key; and a public key.

It is further appreciated that various sub-combinations of the secure system 200 may comprise alternative preferred embodiments of the present invention. For example, and without limiting the generality of the foregoing, each of the following may comprise an alternative preferred embodiment of the present invention: any one of the secure devices 220; the trusted entity 210; and any one of the symmetric certificates.

Reference is now made to Fig. 4, which is a simplified flowchart illustration of a preferred method of operation of the system 10 of Fig. 1.

Preferably, a secure communication system that employs a public-key infrastructure (PKI) scheme is provided (step 300). A certifying secure entity and first and second secure devices are also preferably provided (step 310). A certificate is then preferably used (step 320) to permit the first and second

secure devices to communicate with each other. The certificate preferably comprises the following certificate fields: a certificate field comprising an indication of identity of a secure device to which the certificate pertains; a certificate field comprising a public key; and at least one of the following certificate fields: a certificate field comprising a level of security of a timer used in the secure communication system; a certificate field comprising a level of security of an NVM of the secure device to which the certificate pertains; a certificate field comprising a level of implementation of export to another secure communication system; a certificate field comprising an identification of at least one encryption mode supported by the secure device to which the certificate pertains; and a certificate field comprising a rendering type specification.

Reference is now made to Fig. 5, which is a simplified flowchart illustration of a preferred method of operation of a secure device in either the system 10 of Fig. 1 or the system 200 of Fig. 3. Preferably, a first secure device which communicates in a secure communication system that employs a public-key infrastructure (PKI) scheme is provided (step 400). The first secure device preferably receives (step 410) a certificate from a certifying secure entity in the secure communication system. The certificate preferably comprises the following certificate fields: a certificate field comprising an indication of identity of a second secure device; a certificate field comprising a public key; and at least one of the following certificate fields: a certificate field comprising a level of security of a timer used in the secure communication system; a certificate field comprising a level of security of an NVM of the second secure device; a certificate field comprising a level of implementation of export to another secure communication system; a certificate field comprising an identification of at least one encryption mode supported by the second secure device; and a certificate field comprising a rendering type specification.

Preferably, the first secure device checks (step 420) the certificate to determine authenticity of the certifying secure entity, identity of the second secure device, and whether a comparison between security levels comprised in the certificate fields and corresponding values in a content license received at the first

secure device and at the second secure device indicates that security permission may be issued, and, if such checking validates the certificate and results in an indication that security permission may be issued, the first secure device preferably issues security permission. Then, exchange of information between a first communication appliance associated with the first secure device and a second communication appliance associated with the second secure device is preferably enabled (step 430) in accordance with the security permission.

Reference is now made to Fig. 6, which is a simplified flowchart illustration of a preferred method of operation of the system 200 of Fig. 3. The method of Fig. 6 is self-explanatory.

It is appreciated that software components of the present invention may, if desired, be implemented in ROM (read only memory) form. The software components may, generally, be implemented in hardware, if desired, using conventional techniques. It is appreciated that various features of the invention which are, for clarity, described in the contexts of separate embodiments may also be provided in combination in a single embodiment. Conversely, various features of the invention which are, for brevity, described in the context of a single embodiment may also be provided separately or in any suitable subcombination. It will be appreciated by persons skilled in the art that the present invention is not limited by what has been particularly shown and described hereinabove. Rather the scope of the invention is defined by the claims which follow: