WWW/Internet - Portal do Software Público Brasileiro

IADIS International Conference WWW/Internet 20102. GRIMEN PROTECTION MODEL LIFE CYCLEGrimen et al. [Grimen-DRM2] proposed an architecture for software-based secure content distribution thatconsists of four players: the content provider (CP), the stream server, which we are going to call the contentserver (CS), the viewer software (VS) and the security server (SS). The CP encodes the content media, anddivides it into many pieces. It then produces as many symmetric keys as there are media pieces, in order toprotect each piece with one unique symmetric key. This process results in what they called an encryptedencoded media document (EEMD) and makes it ready for distribution. See Figure 1. The authors called thetime period for each piece a trust interval.The CS is in charge of distributing the EEMD piece by piece. The VS player is running within the userenvironment. It is responsible for decrypting and decoding the EEMD and then rendering the content mediaand making it available for viewing. The SS is responsible for generating and delivering a piece of codecalled a Mobile Guard (MG), which is able to execute in the user environment. The MG needs to be pluggedinto the VS. The MG needs to be sent to the VS in order to configure the VS to maintain security states ofthe media document. The MG is responsible for checking the integrity of the VS components, including theMG itself, and then after successful integrity checking, the SS is going to deliver a corresponding media keyfor a current delivered piece of the EEMD. The authors claim that the MG is hard to compromise; ifsuccessful software modifications happens, it will be detected and the system will have “break once breakeverywhere resistance” [Grimen-DRM2].Figure 1. Dividing the media content [Grimen-DRM2].As the encoded media document is being split into multiple pieces, each piece is encrypted with adifferent key. The SS is going to provide the decryption key for each piece only at the start of its particulartrust interval, upon request and after checking the integrity of VS; the VS needs to prove its good intentionbefore delivery of the new decryption key. This good intention is achieved when the VS receives andexecutes a new generated MG, which means that for every decryption key there is a new MG. Each MG isdistinct from the others, and each one is responsible for reconfiguring and securing the VS. The MG needs tobe obfuscated to prevent the software hacker from predicting the internal logic of the MG [Grimen-DRM2].The MG is replaced for each trust interval, in order to prevent the software attacker from predicting theVS configuration when he has the time to gain the knowledge. Each instance of the MG is responsible forprotecting the access control mechanism used by the VS for the duration of the trust interval. Each MGinstance is going to check the integrity of the VS every new trust interval. The VS is going to request thecorresponding decryption key at the end of each trust interval. The SS is responsible for receiving thechecksum for the VS for each trust interval. Then, upon verifying the correctness of each checksum, it isgoing to send the next decryption key that corresponds to the new media piece. Figure 2 shows the Grimenet al. proposed architecture. The details of the process of receiving the decryption key for each trust interval(as proposed by Grimen et al. [Grimen-DRM2]) are as follows: The VS generates a random unpredictable transport key. The MG executes and determines the integrity checksum of the VS along with the MG itself. The integrity checksum is determined by computing a one-way hash function across the VSinstructions, the MG instructions, MG’s public key and the generated transport key. See Figure 5. The VS encrypts the transport key with the SS public key. The VS sends the encrypted transport key to the SS along with the integrity checksum. The SS verifies the checksum. Since the SS can extract the transport key, and since it knows the VSinstructions, the MG instructions, MG’s public key and the generated transport key, the SS can then generate67