WWW/Internet - Portal do Software Público Brasileiro

ISBN: 978-972-8939-25-0 © 2010 IADISthe checksum. The SS verifies the calculated checksum against the received checksum. If the verification issuccessful, the SS encrypts the corresponding trust interval's media key with the transport key and sends it tothe VS. The VS now can decrypt the corresponding piece of the EEMD. See Figure 3.Figure 2. Grimen et al. proposed system architecture [Grimen-DRM2].Figure 3. Key exchange protocol [Grimen-DRM2].We analyzed the presented protocol and found two security attacks. The first attack happens becausethere is nothing that can prevent the software attacker from forwarding the MG to another VS, and then theforwarded MG produces a new transport key and sends that key to the SS. There is nothing to tell the SS thatthe MG is a copy, not the original. In this case the server will respond with the media key encrypted with thenew generated transport key provided by the pirated MG. Another attack appears because the generation ofthe transport key is done by the VS, because the VS executable file is stored in the client environment. Thusthe client has the chance to statically or dynamically analyze the code and learn the memory address of thetransport key.The main problem with this key exchange protocol comes from the fact that there is nothing to distinguishany instances of MG. All of them have the same features and no individualization technique has beenattached to them. The secondary problem is due to the fact that the client has enough time to statically ordynamically analyze the VS. One way to prevent the previous attacks is to individualize the MG for eachclient and to store the transport key in an unpredictable place. In the next Section we will discuss how toachieve both goals.3. ATTACK ANALYSISAutomated Validation of Internet Security Protocols and Applications (AVISPA) is a tool used for formalmodeling and analyzing of Internet security protocols. The model is specified in high level protocolspecification language (HLPSL), which represents the message exchanged between participants. Thoseparticipants represent roles that send messages and receive messages, these messages may contain thenecessary keys needed to establish secure sessions and convey authentication actions between roles[AVISPA-Manual]. We translated the Grimen et al. key exchange proposal into the following messages:1- MG -> S: {Nm|Tki|MG}_Ks | hash(MG|VS|Nm|Tki)Where MG: The identity of the mobile guardS: The identity of the security serverNm: nonce generated by MG for authentication purposes.68