Privacy against piracy: Protecting two-level revocable P-K traitor tracing

In known traitor tracing schemes, an enabling block is used for both secure broadcast of a session key and tracing traitors in pirate boxes. This paper suggests a new traitor tracing scheme that has two-levels for efficiency. In the more frequent level an enabling block is used only for a very efficient session key distribution, and a new block, less frequently used, called a renewal block is used for the renewal of the group key and for the detection and revocation of traitors. This organization increases efficiency: the computational complexity of encryption/decryption of the often employed enabling block is constant, while only that of the sporadically employed renewal block depends on the allowed revocations (as in earlier schemes). However, our saving has a price: in a two-level broadcasting scheme, the new danger is that rather than performing piracy by leaking the keys of the renewal block, the individual traitors may leak to pirates the means to decode the enabling blocks at the sessions. For example, if the enabling block is naively implemented as a single key-encrypting-key that is known to all– and this key is used to encrypt session keys, then any participant can leak this key without being detected. (Note that leaking the session keys themselves, constantly all the time, is typically considered in the literature not to be an economically viable option). In order to prevent this new potential leakage, a novel idea of personal enabling keys (used throughout) is suggested. In order to get a session key, a user will need access to the enabling block with his own personal key. To discourage leakage of the personal key (which would violate the service), a novel self-enforcement method is employed that ties “privacy” to “leakage”. The self-enforcement of personal keys uses the fact that if the key is leaked then the party which leaks may lose its private data to the party it leaks to (i.e. it is a privacy-based protection mechanism). In our self-enforcement, a subscriber’s private information is not embedded into his personal key directly (as was done earlier). Thus, if a subscriber’s important data is altered, his personal key needs not to be regenerated. The separation into two-level broadcast (for efficiency) together with the novel flexible self-enforcement (privacybased protection of the enabling-block keys) is the central contribution of this work.