MINZKN의 블로그

본 내용은 위키백과(http://ko.wikipedia.org/wiki/%EC%9C%88%EB%8F%84_%EB%AF%B8%EB%94%94%EC%96%B4) 에서 소개된 링크중에 http://www.spinnaker.com/crypt/drm/freeme/Technical 부분에서 밸췌한 것임을 밝힙니다.br /br /br /br /br /br /br /pre-----BEGIN PGP SIGNED MESSAGE-----br /br /br / Microsoft's Digital Rights Management Scheme - Technical Detailsbr / By Beale Screamerbr /br /br /This document describes version 2 of the Microsoft Digital Rightsbr /Management (MS-DRM), as applied to audio (.wma files). The sourcesbr /for this material are varied, and some of the information might bebr /slightly incomplete; however, the fundamental ideas are solid andbr /easily verified. There is no attempt at describing the older versionbr /1 of DRM. While version 1 is widely used (probably more widely thanbr /version 2!), and the scheme is somewhat simpler, the purpose of thisbr /is to describe the latest technology and not necessarily allow allbr /existing systems to be broken. The ideas described here are alsobr /implemented in the software originally distributed with this documentbr /(but as an independent piece, so the software may or may not bebr /available from where you have obtained this document), so a realbr /implementation can be examined. Not all of the information here isbr /needed in order to write the software that removes the encryption, butbr /some of the more interesting points surrounding the MS-DRM scheme andbr /software are given even if not necessary. Also note that no code isbr /included in this document, either real code or pseudo-code. Allbr /that's in this document is a straight mathematical discussion, whichbr /should be fully protected under the 1st Amendment to thebr /U.S. Constitution. I have no doubt that the corporate entities thatbr /this document offends will attempt to suppress it, but I don't thinkbr /any argument they make could hold up to Constitutional scrutiny.br /br /The basic components of MS-DRM involve use of elliptic curvebr /cryptography (ECC) for public key cryptography, DES for a blockbr /cipher, RC4 for a stream cipher, and SHA-1 for a hash function. Therebr /is also a block cipher which I haven't seen before, used in the MS-DRMbr /system to build a MAC, or keyed hash function. This cipher will bebr /explained completely below, and while the remaining algorithms arebr /well-known, more will be said about Microsoft's use of ECC below.br /br /In the discussion and examples below, all numbers are expressed inbr /hexadecimal in the standard ordering (most-to-least significant)br /unless otherwise stated. The actual bytes comprising large numbers inbr /any code are stored little endian, so at times it is convenient tobr /look at data in that ordering, and this will be clearly marked when itbr /is done.br /br /One confusing item is that binary data sent back and forth is encodedbr /using Base64, but not using the standard algorithm! For some reason,br /Microsoft has decided to use the non-alphanumeric character '*'br /instead of '/', and '!' instead of '+' in some places, and in otherbr /places they replace '/' with '@' and '!' with '%'. This means thatbr /any software dealing with these strings cannot use a standard Base64br /decoder, but must use a custom-build decoder.br /br /br /FILES INVOLVEDbr /br /Several key DLLs are kept in \windows\system that relate to the MS-DRMbr /scheme.br /br / drmv2clt.dll: Provides basic DRM version 2 functionalitybr /br / blackbox.dll: Provides basic, machine-specific crypto for MS-DRM.br / Functionality replaced by IndivBox.key when the localbr / system has been individualized.br /br /The other interesting place for files is in \windows\All Users\DRMbr /(this location is not necessarily fixed but comes from the registrybr /entry HKEY_LOCAL_MACHINE\Software\Microsoft\DRM\DataPath). Here's abr /sampling of some of the files in this directory (these are hiddenbr /system files, so be sure to turn on view all files in order to seebr /them!):br /br / IndivBox.key: Despite the extension, this is really a DLLbr / that is an individualized version of blackbox.dllbr /br / drmv2.lic: The file of licenses (a structured IStorage file)br /br / drmv2.sst: Secure state for each of the licenses. Also an IStoragebr / file, but each stream is RC4 encrypted.br /br / v2ks.bla: The version 2 key store - this is where all the public/privatebr / keys are kept (encrypted, of course!).br /br / v2ksndv.bla: The individualized version 2 key store.br /br /br /A SIMPLE BLOCK CIPHER (MULTISWAP)br /br /Microsoft is using a very simple block cipher to create a messagebr /authentication code (MAC). As this is not a standard algorithm, Ibr /will describe it fully. The main operations in this cipher arebr /32-bit multiplications and swaps of the two halves of 32-bit words, sobr /I have called this cipher the MultiSwap cipher.br /br /The MultiSwap cipher works on 64-bit blocks, using a key that consistsbr /of 12 32-bit words, and a current state (or initialization vector)br /that is 64-bits long. In the Microsoft implementation, the leastbr /significant bits of all 12 words are set to 1, although once thebr /cipher is understood it is clear that really only 10 of the wordsbr /require this bit to be set. The basic operation of the cipher is abr /transformation that is done on the first 32-bit word of the plaintextbr /block using the first 6 key words, and then repeated for the otherbr /plaintext word and remaining key words.br /br /Let k[0], k[1], k[2], k[3], k[4], and k[5] denote the first 6 keybr /words, and let s[0] and s[1] denote the two words of the state. Tobr /transform a 32-bit input word x, first define the following functionbr /br / f(a)=swap(swap(swap(swap(swap(a*k[0])*k[1])*k[2])*k[3])*k[4]) + k[5]br /br /where * is multiplication modulo 2^(32), and swap is an operationbr /which exchanges the two 16-bit halves of a 32-bit word. The completebr /transformation of a 32-bit word x then consists of s[1]=s[1]+f(x+s[0])br /and s[0]=f(x+s[0]). This is first done with the value x set to thebr /first 32 bits of the input, and then repeated with x set to the secondbr /32 bits and the using keys k[6] through k[11]. The output of thebr /block cipher is the new state s[0] and s[1].br /br /The reason this block cipher can be inverted is because all the keybr /words are odd, which means they have multiplicative inverses modulobr /2^(32). To invert f(), just do the operations in the reverse order:br /first subtract off k[5], then do the multiply/swap operations with thebr /inverses of k[4] through k[0]. Notice that only the multiplicativebr /key words really need to be odd, so there is no reason for the leastbr /significant bit of k[5] or k[11] to be set; however, Microsoft setsbr /these bits anyway.br /br /This block cipher is never used for encryption, but is used to createbr /a message authentication code (MAC) in the standard way. Assuming thebr /length of the message to be hashed is a multiple of 8 bytes (64 bits),br /the cipher is initialized with a state of all zeros, and then used tobr /encrypt the entire data. The output of the last block (the finalbr /state) is the MAC for that message. This is used in computing packetbr /keys to encrypt protected content by MS-DRM, as will be explainedbr /later.br /br /br /ELLIPTIC CURVE CRYPTOGRAPHYbr /br /For ECC, Microsoft is using an elliptic curve over Zp, where p is abr /160 bit prime number (given below). The curve consists of the pointsbr /that lie on the curve y^2=x^3+ax+b, where the operations are done overbr /the field Zp and a and b are coefficients that are given below.br /br /All values are represented as packed binary values: in other words, abr /single value over Zp is encoded simply as 20 bytes, stored in littlebr /endian order. A point on the elliptic curve is therefore a 40 bytebr /block, which consists of two 20 byte little endian values (the xbr /coordinate followed by the y coordinate). Here are the parameters forbr /the elliptic curve used in MS-DRM:br /br / p (modulus): 89abcdef012345672718281831415926141424f7br / coefficient a: 37a5abccd277bce87632ff3d4780c009ebe41497br / coefficient b: 0dd8dabf725e2f3228e85f1ad78fdedf9328239ebr / generator x: 8723947fd6a3a1e53510c07dba38daf0109fa120br / generator y: 445744911075522d8c3c5856d4ed7acda379936fbr / Order of curve: 89abcdef012345672716b26eec14904428c2a675br /br /These constants are fixed, and used by all parties in the MS-DRMbr /system. The nerd appeal of the modulus is high when you see thisbr /number in hexadecimal: it includes counting in the hexadecimal, asbr /well as the digits of fundamental constants e, pi, and sqrt(2).br /br /In order to use this public key system, any user must have abr /private/public key pair. Since the security of the system reliesbr /pretty heavily on the private keys remaining secret (even from thebr /user of the system on which they reside), they are carefully hidden.br /In fact, there are keys hidden in various files that are used,br /including blackbox.dll, v2ks.bla, and IndivBox.key. For example, oncebr /the player has been individualized, IndivBox.key is created, and therebr /are at least two keys embedded into this file: a 64-bit key used forbr /RC4, and a 160-bit private key for use in ECC. The ECC private key isbr /used as the basic client key (the corresponding public key is storedbr /unencrypted in the key store file, and used as the initial part of thebr /client id sent when requesting a license), and additional key pairsbr /are stored in part of the keystore file (v2ks.bla or v2ksndv.bla),br /encrypted with the RC4 key.br /br /These secret keys are stored in linked lists that contain 32 bits perbr /node (so the key as a whole is not in contiguous memory), interspersedbr /with the code in the library (IndivBox.key for example). The idea isbr /that they can be read by that library, used internally by thatbr /library, and never communicated outside the library. Since thebr /IndivBox.key file is shuffled in a random way for each client, thesebr /keys would be extremely difficult to extract from the file itself.br /Fortunately, we don't have to: these keys are part of the object statebr /that is maintained by this library, and since the offset within thisbr /object of these secret keys is known, we can let the library itselfbr /extract the secret keys! The code for this simply loads up the blackbr /box library, has it initialize an instance of the object, and thenbr /reads the keys right out of that object. This is clearly a weaknessbr /in the code which can be corrected by the DRM software fairly easily,br /but for now it is the basis of our exploit.br /br /br /GETTING A LICENSEbr /br /Each protected media file is encrypted with a content key that willbr /unlock the packets of the media stream. We describe briefly how abr /license (containing a content key) is obtained for informationbr /purposes, but the license acquisition protocol is not really importantbr /for unlocking that content. Simply use the MS Media player, have itbr /request and decrypt the licenses, store them in drmv2.lic, and then webr /can extract them directly from that file.br /br /A protected media file is apparently recognized by the presence of abr /DRMV2 object in the .wma file header. This object has GUIDbr /298ae614-2622-4c17-b935-dae07ee9289c, and contains an XML object 6br /bytes into the data part of the object. Among other things, thisbr /header contains a KID element identifying the key used to unlock thebr /content. The drmv2.lic file is then checked to see if a license withbr /this KID exists locally. If the license doesn't exist, a licensebr /request is formed, which sends an encrypted client id to the licensebr /server. This is sent as a challenge, which consists of 168 bytes inbr /the MS-Base64 encoding. The first 80 bytes are two ECC points, whichbr /make up an ECC encrypted random session key, and the remaining 88br /bytes are the client id encrypted using RC4 and the session key.br /The ECC encryption is done using a public key that seems to be fixedbr /for all clients, so it is safe to assume that this corresponds to abr /private key that is common to all license servers and built in to thatbr /side of the system (without access to the server side code, it wasbr /impossible to find the corresponding private key).br /br /After some interaction, the license comes back as mime typebr /application/x-drm-v2, as an escaped XML-encoded license in thebr /following formatbr /br / lt;LICENSERESPONSEgt;lt;LICENSE version=x.x.x.xgt;br / ...base64 encoded license... lt;/LICENSEgt;lt;/LICENSERESPONSEgt;br /br /where x.x.x.x is most likely 2.0.0.0. To make things tricky for abr /sniffer, the license is actually RC4 encrypted using the same sessionbr /key that was established by the client when sending the challenge.br /The client then decrypts the license and stores it in the drmv2.licbr /file.br /br /br /GETTING THE CONTENT KEYbr /br /Getting the content key from a license is pretty easy once the clientbr /knows what its public/private key pairs are, and has a copy of thebr /license obtained from drmv2.lic. The license entry is an XML objectbr /with an element for ENABLINGBITS, which has sub-elements ALGORITHMbr /(which should have type MSDRM), PUBKEY, VALUE, and SIGNATURE. Thebr /PUBKEY element should match one of the client's public keys, or elsebr /there a problem! The VALUE element is the ECC-encrypted content key,br /which can be decrypted by the private key that corresponds to thebr /given PUBKEY.br /br /The content key has a specific format: the y coordinate is ignored,br /and when the x coordinate is written in storage order (little endian),br /the first byte is the length of the content key (which may always bebr /7), which is followed by that many bytes of the content key. Whilebr /the content key is tied to the encoded media file (which may be commonbr /to many users), the enabling bits value will be different for eachbr /user, and tied to that user's public/private keys. Because of this,br /licenses are not transferable from one user to another, even thoughbr /the media files themselves are (the new user must obtain his ownbr /license from the license server).br /br /We go through an example now of finding a content key. In thisbr /example, we have identified our public and private keys as thebr /following values:br /br / Public key x: 1957f96f3327a25bba52166ad7fcc74087b9734bbr / Public key y: 8939e1b1ed988182d34d17ebbcb0e03a82d062e7br /br / Private key: 757ff01b853496452eea0b0646c3a357a6f33509br /br /We're looking at a file RIAALuvsMe.wma, and find in the header thebr /following bit of XML:br /br / lt;KIDgt;nA67jM7dNGIUQIkP5v7hSQ==lt;/KIDgt;br /br /The actual KID seems to be a Base64 encoding of a GUID, but it isbr /treated as a string (uninterpreted) by the software, so the originbr /doesn't seem to make much difference.br /br /The license is inside the drmv2.lic file, which is a structured DOCbr /file, meaning it can be accessed through the IStorage and IStreambr /interfaces (and it can be browsed by the Microsoft Visual Studio DOCbr /File Viewer tool if you're curious). The top level drmv2.lic filebr /has a lower-level IStorage object for each KID, which can contain abr /set of licenses for each KID. In order to guarantee valid IStoragebr /names, the KID is first processed to change all '/' characters to '@',br /and all '!' to '%'. The names of the IStream objects containing thebr /licenses again look like Base64 encoded GUIDs, which turn out to bebr /the LID (license ID?) element stored in the license. This can bebr /verified once the license is obtained, but we're not sure how tobr /generate LID's from the content header information, and so can'tbr /directly open the appropriate LID stream. Instead, we simplybr /enumerate through all available streams for this KID, testing each onebr /for a PUBKEY element (see below) that we know. This is taken to bebr /the license for this content. While this is really just a guess as tobr /the proper workings, it seems to work fine in all our tests.br /br /Inside the license we find the following XML (this has been formattedbr /so that it's easier to look at - in the actual file this would all bebr /on one line).br /br / lt;ENABLINGBITSgt;br / lt;ALGORITHM type=MSDRMgt;lt;/ALGORITHMgt;br / lt;PUBKEY type=machinegt;br / S3O5h0DH*NdqFlK6W6InM2*5VxnnYtCCOuCwvOsXTdOCgZjtseE5iQ==br / lt;/PUBKEYgt;br / lt;VALUEgt;br / VEsbPedfwrybrpkg0fhoOfe5eB9ef0R7QTxgX7NbtMIFK!h*4Pk7ekbr / PUqlDIRqYwQkgCGE0r0qtQdCUYszT!b7XedCIpsApQjstaFmafahM=br / lt;/VALUEgt;br / lt;SIGNATUREgt;br / KpxCm6lSXH8dTPI359jToftSEuLiP9v*zpHAy!kDEhlYkw6mkfQzlg==br / lt;/SIGNATUREgt;br / lt;/ENABLINGBITSgt;br /br /The SIGNATURE element above is just random garbage. We didn't make abr /real signature for this example (among other things, we don't have abr /certified public key, which would have to follow this in a realbr /license. Requiring such a signature keeps people from creating theirbr /own licenses, since only those that have been issued validbr /certificates can do so).br /br /First look at the PUBKEY part. If this is run through a Base64br /decoder (modified for the MS character set as described earlier) youbr /get the following binary values, shown below as a memory dump:br /br / 0000: 4B 73 B9 87 40 C7 FC D7 6A 16 52 BA 5B A2 27 33 br / 0010: 6F F9 57 19 E7 62 D0 82 3A E0 B0 BC EB 17 4D D3 br / 0020: 82 81 98 ED B1 E1 39 89 br /br /Notice how this is exactly our public key from above, stored in littlebr /endian order! So this license is for our machine.br /br /Next, take the VALUE element above, run it through a Base64 decoder,br /and interpret the 80 byte result as 4 20-byte values stored in littlebr /endian order. These four numbers are as follows:br /br / Encrypted u.x: amp; 1f78b9f73968f8d12099ae9bbcc25fe73d1b4b54br / u.y: amp; 7a3bf9e07fe82b05c2b45bb35f603c417b447f5ebr / v.x: amp; 18257450abd22b4d1802484230a646c850aad443br / v.y: amp; 136a9f66165acb8e500ab0292274deb56ffe34b3br /br /To decrypt this value, first we multiply the point u by our privatebr /key, resulting in the pointbr /br / x: 399c72d525a9b65b7543a3e3adc88ce0f6a38db5br / y: 66cfa6bdbfbb93b906b22deb36792363d8e8adc2br /br /and then subtract this point from v to getbr /br / x: c91590616b4b3707br / y: 753e24e50d437e147b4998376f163dc27b639a7abr /br /Since x is so short, we have almost certainly gotten our content key.br /Writing in storage order (little endian), x isbr /br / 0000: 07 37 4B 6B 61 90 15 C9br /br /which means that the content key has length 7 (from the first byte),br /and the actual key is the string of bytes 374B6B619015C9.br /br /br /DECRYPTING THE CONTENTbr /br /The content encryption process is simpler to explain than decryption,br /so we start with that. The content key is not used directly, but isbr /processed for several different uses. First, the content key isbr /hashed using the SHA-1 hashing algorithm, producing a 20-bit output.br /The first 12 bytes of this output are used as an RC4 key, and a blockbr /of 16 words (or 64 bytes) of zeros is encrypted. The leastbr /significant bits of the first 12 words of this output are all set, andbr /are used as the MultiSwap key. The next 2 words are the encryptionbr /in-whitening mask and the next 2 words are the encryptionbr /out-whitening mask (this will be explained later). The last 8 bytesbr /of the original SHA-1 hash output are used as a DES key.br /br /To encrypt the content so that packets can be accessed randomly (forbr /seeks), the content cannot be encrypted as one single stream.br /However, to strengthen the cipher we also don't want to re-use thebr /same key for every packet. To satisfy both of these goals, MS-DRMbr /uses the following scheme to encrypt a packet: First, the packet (withbr /size rounded down to a multiple of 8 bytes) is run throughbr /MultiSwapMAC to produce a 64-bit MAC. For some reason, the 32-bitbr /halves of this MAC are swapped before further processing. Next, thebr /entire packet is RC4 encrypted using the swapped MAC as an 8-byte RC4br /key. The 8-byte MAC (with swapped halves) is then run through abr /whitened DES by first XORing with the in-whitening mask, thenbr /running through DES (using the DES key from the last paragraph), andbr /then XORing the result with the out-whitening mask. The resulting 8br /bytes are then placed in the final encrypted packet, overwriting thebr /last full 8-byte block (not the last 8 bytes of the packet, butbr /blocking the packet from the beginning into 8 byte pieces, andbr /overwriting the last full piece).br /br /To decrypt such a packet, first locate the last full 8-byte block, runbr /it through the whitened DES decryption, and the result is used as anbr /RC4 key to decrypt the packet. This will produce the correct packetbr /except for 8 bytes: those in the position of the last full 8-bytebr /block are wrong, since they were overwritten in the last phase of thebr /encryption. However, by swapping the halves of the RC4 key, we havebr /the MAC for the original packet up to and including the original bytesbr /in this position. Since the MAC is actually created out of a blockbr /cipher, we can recover the original 8 bytes as follows: run the entirebr /packet through MultiSwapMAC up to the block in question, but notbr /including it. This output is the next-to-last state seen bybr /MultiSwapMAC in the encryption MAC computation, and we just recoveredbr /the final output of the MAC, so we can put these two values into thebr /block cipher decryption to obtain the original data of this 8-bytebr /block. The original 8-bytes are placed back into the packet, and nowbr /the entire original contents are restored!br /br /This is a pretty clever scheme: by using a MAC constructed from abr /block cipher, individual packet keys can be computed and encoded intobr /the encrypted packet with absolutely no increase in space, and sincebr /the size is maintained nothing in the structure of the content filebr /(describing packet sizes or other parameters) needs to be changed atbr /all. The encrypted content can be completely transparent tobr /applications that deal with .wma files in a non-content-sensitivebr /manner.br /br /We finish this section showing an example of content decryption, usingbr /the content key from the previous paragraph. We first process thebr /content key by running it through SHA-1 to obtainbr /br / 15 CB 92 F9 97 2E C8 75 29 4F 12 65 36 B6 C6 DB AC A2 40 35br /br /The first 12 bytes are used as an RC4 key to encrypt a block of allbr /zeros, givingbr /br / 0000: 80 0A 2D 48 D1 FD 7E ED 83 69 4A 7D A5 D5 EE C4br / 0010: 4E E1 64 52 D1 71 98 26 9A F3 14 E3 51 C8 B6 92br / 0020: D4 93 E4 57 97 6D 63 EF 0E 06 07 54 F7 DD ED 38br / 0030: E8 CA A0 D0 83 13 F1 DB C1 70 AE 56 61 7D FB 94br /br /The first 48 bytes are interpreted as 12 32-bit words, stored littlebr /endian, and are saved as the MultiSwap key after setting all leastbr /significant bits. So the key values are k[0]=0x482D0A81,br /k[1]=0xED7EFDD1, etc. The last 16 bytes of the RC4-encrypted blockbr /are the whitening masks for DES, and the key for DES is given as thebr /last 8 bytes of the SHA-1 hash value.br /br /Assume we get a packet with size 1450 bytes, which is 181 8-bytebr /blocks followed by 2 additional bytes. Numbering the byte positionsbr /as 0 through 1449, we look at the bytes in positions 1440 through 1447br /(the last full 8-byte block), and find that they arebr /br / A8 49 65 36 A2 33 18 09br /br /XORing with the encryption out-whitening mask (the last 8 bytes frombr /the RC4-encrypted block above) we getbr /br / 69 39 CB 60 C3 4E E3 9Dbr /br /and decrypting with DES using key 36 B6 C6 DB AC A2 40 35 givesbr /br / FD EF 98 7D 8B 77 72 FDbr /br /and finally XORing with the encryption in-whitening mask (thebr /next-to-last 8-byte piece in the RC4-encrypted block above) givesbr /br / 15 25 38 AD 08 64 83 26br /br /This is then used as an RC4 key to decrypt the packet. To replacebr /bytes at positions 1440 through 1447 with the correct values, takebr /the RC4 value and swap the words around to getbr /br / 08 64 83 26 15 25 38 ADbr /br /This is the MultiSwapMAC of the input packet using bytes 0 throughbr /1447. We run bytes 0 through 1439 through MultiSwapMAC to getbr /br / D9 F7 D9 53 A9 6E 14 D9br /br /and then use this as the state input, along with the original MACbr /output as the data input to the MultiSwapDecode function to obtainbr /br / DA 05 D8 EB 97 FE 1E 7Bbr /br /These 8 bytes are placed in positions 1440 through 1447, and then thebr /entire original packet is restored.br /br /br /OTHER ISSUESbr /br /Communication between different DLL modules is encrypted and checkedbr /at multiple points. This works roughly as follows: Objects arebr /initialized with communication parameters by sending certified publicbr /keys to the object you want to communicate with. The second objectbr /verifies these certificates, generates a random session key (which itbr /uses to generate a MultiSwap key in addition to the use as a sessionbr /key), and sends the encrypted session key back to the calling object.br /Future sensitive communication is RC4 encrypted with the session key,br /and run through MultiSwapMAC to verify integrity (after padding withbr /zeros to make the data a multiple of 64 bits). This is done for databr /sent both to and from the object.br /br /Presumably, this is done so that anyone monitoring parameters passedbr /between DLL modules wouldn't see any sensitive data, although itsbr /use for this purpose is pretty limited. However, it does lead to somebr /interesting and strange situations: when blackbox is sent a packet tobr /decrypt, it decrypts it, and then immediately *re-encrypts* it usingbr /the session key to send it back to the media player! So in decryptingbr /a packet, the computer actually goes through a decrypt/encrypt/decryptbr /sequence of operations!br /br /One very important effect of this scheme is that Microsoft fullybr /controls who gets to write modules that interact with the basicbr /Microsoft media modules. Without a certified public key (and thebr /corresponding private key) it is impossible to write a compatible DLLbr /that interfaces with their code. Since Microsoft controls the issuingbr /of certified public keys, they also have complete control over who isbr /allowed to make compatible and competing products. Microsoft'sbr /reputation for being generous to competitors is well-known, so thisbr /effectively gives Microsoft a technically guaranteed monopoly power.br /br /Of course, these certificates and private keys must be distributedbr /with any Microsoft blessed software as well, and in fact exist inbr /the media player and blackbox DLLs. They're not hard to extract, ifbr /you know where to look, but I won't give them here. They would be ofbr /limited use anyway, since Microsoft also has a revocation listbr /mechanism built in to the Media player software, meaning that they canbr /revoke any of these certificates at their whim, remotely disabling anybr /software that depends on that certificate for communication.br /br /br /br /br /br /-----BEGIN PGP SIGNATURE-----br /Version: 2.6.2br /br /iQCVAwUBO5qt3JCr1f2GXCalAQE8ygP9Gb4Dm0ZQ5GePjAIfMFyqYVtUNSUUfj7Abr /3ZLwbMwUtnRHeYDGWRJEqvJMPf4SujKHcwQL3LtefrhH7dOn6r4AyUQV6ymezpd/br /AMY53ONufawU+T8YgilEe2WCDRc4Y/uDbQFZIhcPQ+H78nzFSvdj+FzQ7pKrxsIrbr /QWe1ZNP4xfY=br /=WL0qbr /-----END PGP SIGNATURE-----br //prebr /

크리에이티브 커먼즈 라이센스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.