WWW/Internet - Portal do Software Público Brasileiro

ISBN: 978-972-8939-25-0 © 2010 IADISsolution to prevent the previous attack is to give the ability for the SS to distinguish each MG instance. Wecan achieve this distinction by individualizing all legal MG copies.4. INDIVIDUALIZATION PROCESSApple's DRM solution used three keys to protect its products: master key, repository key and client key. Theproduct media is encrypted with the master key, the master key is encrypted with the client key, and theencrypted master key is attached to the protected content. When the user asks for a license to use the productmedia, the server that locally stores the client key sends the requesting user a license that includes the clientkey encrypted with the repository key. The application that presents the product media at the client side hasthe repository key and is attached with a secret algorithm embedded in the presentation software. Theprotection mechanism is dependent on keeping the secret algorithm hidden from the user. Each user has adistinct client key and repository, which simplifies the license individualization process. The client key israndomly created by the server and saved in the server's database for further use. The repository key iscalculated from serial number of the first hard disk, BIOS version, CPU name and windows ID, which isassumed to be unique [Grimen-DRM1].In the Microsoft DRM solution the product media are encrypted with a content key and the content key isencrypted with client keys. When the user asks for a license to use the product media, the license server sendsthe license that contains the encrypted content key to the user. In the client side, there is a blackbox file thatcontains the client key. Each client has an individualized blackbox, which means each instance of a blackboxcan only work for a specific machine. The protection mechanism relies on keeping the blackbox hidden fromthe user access, which simplifies license individualization process [Grimen-DRM1].OMA DRM standard encrypts the product media with a content encryption key (CEK), the CEK isencrypted with a DRM agent’s public key and then inserted into a right object (RO). This processcryptography binds an RO into DRM agent. Each DRM agent has a unique public and private user key; whena DRM agent asks for right object to use a specific product, the server, who is responsible for creating rightobjects, can obtain the DRM agent's public key, and create a unique right object for each DA that includesthe CEK key, which is encrypted with a DA’s public key. Only the DA who has the corresponding privatekey can use that RO and get the CEK [OMA-DRM2.1].From the previous solutions we have two software solutions and one hardware solution for the end-userindividualization process. The case that we are working with needs to prevent an end user from forwardingthe MG to another user. To do this, we need to individualize each MG and make MG code not to work onany other user. We suggest that the SS, which is responsible for generating an MG, needs to authenticateeach user and then embed a unique identity (Ticket) in the MG. The security server is going to accept onlyone request for media decryption key from each legal MG instance per trust interval. Due to the fact that thegeneration of transport key is unpredictable to both SS and user, the ticket value along with generatedtransport key will be the unique identifier for each MG per trust interval. When the SS receives two requestsfor the same MG that have the same ticket and a different transport key, the second key request will notreceive any response. This will prevent a pirated MG instance from successfully attacking the business modelpreviously discussed. Here is the modified protocol:1- MG -> S: _{Nm|Tki|MG|Ticket}_Ks}_Km | hash(MG|VS|Nm|Tki|Ticket)2- S-> MG: {Nm|Ns|S}_Km3- MG-> S: {Ns|MG}_Ks4- S->MG: {Mki|S}_TkiWhere Km here is a symmetric shared key between the MG and the SS, and the Ticket is the unique valuefor each generated MG.Before SS delivers an MG to a valid VS, it embeds a symmetric key Km into the generated MG. If alegitimate user receives a valid MG, and then forwards that received MG to his friend, both MGs will havethe same identity (ticket). Each MG is going to run and generate a unique transport key at the client host; thismakes a checksum calculation unique since the transport key is one of the hash function inputs. We will callthe result of the hash function a checksum. When both MGs send the first message, which contains: nonce,random generated transport key, mobile guard identity and ticket all encrypted with the SS’s public key andthen again encrypted with shared key (Ks), the second part of the massage is the checksum. The SS canextract the ticket value and the transport key and use them to calculate the checksum. The SS compares the70