Vista Hacked!

Photos

Vista Hacked!

see larger image

uploaded by yul3452

Exactly a week after Vista hit multiple distribution centers worldwide, it was broken by an individual who was annoyed he could not play back his legitimately-purchased HD-DVD on his HD-DVD player.

    Technically what he broke was the AACS content protection rather than mounting a direct attack on Vista but the end result was that premium content under Vista is now unlocked.

    According to Peter Gutmann, a person using the handle Muslixx64 appears to have figured out how to extract HD-DVD and Blu-Ray keys from the Power DVD player software allowing HD content to be decrypted and played back without content protection measures getting in the way.

    The manufacturers of PowerDVD claim that they've done nothing wrong and won't be updating the player, and muslix64 says that “they [players] are all vulnerable [to a] different extent”.

    As a result, both HD-DVD and Blu-Ray content can now be decrypted and played without image downgrading or blocking by the Vista OS, and unprotected content is already appearing in the usual locations like Bit Torrent streams.

    Peter says: “The fact that the legally-purchased content wouldn't play on a legally-purchased player because the content protection got in the way was the motivating factor for the crack.”
“The time taken was about a week.

    As a result, all of the content-protection technology (at least for HD-DVDs and Blu-Ray discs) is rendered useless. All that remains is the burden to the consumer. It lasted all of one week.”

    Peter adds: “Exactly what will happen when a key is leaked depends on how the attackers handle it. The way HD-DVD/Blu-Ray keying works is that a per-device key is used to decrypt the title key on the disk, and the title key is then in turn used to decrypt the content.

    So the chain of custody is Device key ⇒ Title key ⇒ Content. This level of indirection allows an individual device to be disabled by revoking the device key without making the disk unplayable on all devices, since other device keys can still decrypt the title key and thus the content.

    The device key is tied to a particular device/player/vendor, but the title key is only tied to the content on disk. You can probably see where this is going… by publishing the device key, the attacker can cause general mayhem by forcing device revocation.

    On the other hand by publishing the title key the attacker can release the content in an untraceable manner, since it's not known which device key was used to leak the title key.

    In addition since there's no way to un-publish the title key (encrypted content + title key = unencrypted content), at that point its game over for the content.”

     In what appears to be a bit of an irony,

Windows Vista is attempting to achieve a level of security for premium content that not even the United States Government had attempted to protect its most sensitive secrets.

    In order to prevent tampering with in-system communications, all communication flows within the Vista OS have to be encrypted and/or authenticated.

    For example content sent to video devices has to be encrypted with AES-128. This requirement for cryptography extends beyond basic content encryption to encompass not just data flowing over various (computer) buses but also command and control data flowing between software components.

    Peter revealed: “For example communications between user-mode and kernel-mode components are authenticated with OMAC message authentication-code tags, at considerable cost to both ends of the connection.

    The initial crypto handshake is:

driver -> application: cert + nonce
application -> driver: RSA-OAEP-SHA512( nonce || key || seqNo1 || seqNo2 )

    In this step the driver supplies its certificate to the calling application via DxgkDdiOPMGetCertificate() and a 128-bit nonce via DxgkDdiOPMGetRandomNumber(). This is either a COPP or an OPM certificate, with COPP being the older Windows XP content protection and OPM being the newer Windows Vista one.

    There's also a third type of fleur-de-lis certificate that the driver uses if it has a UAB (User-Accessible Bus).
The certificates contain a 2048-bit RSA key which is used to encrypt a 40-byte payload containing the nonce provided by the driver, a 128-bit session key, and two 32-bit initial sequence numbers (they start at random values), the first number is for status messages via DxgkDdiOPMGetInformation() and the second for command messages via DxgkDdiOPMConfigureProtectedOutput().

    Once the keys are set up, each function call is:

in = OMAC( nonce || seqNo || data )
out = OMAC( nonce || seqNo || data )

    Needless to say, this extremely CPU-intensive mechanism is a very painful way to provide protection for content, and this fact has been known for many years.

    Twenty years ago, in their work on the ABYSS security module, IBM researchers concluded that the use of encrypted buses as a protection mechanism was impractical.”

    “Since [encryption] uses CPU cycles, an OEM may have to bump the speed grade on the CPU to maintain equivalent multimedia performance. This cost is passed on to purchasers of multimedia PCs” — ATI – a graphics card manufacturer -- disclosed.

(Part 4 Windows' other secrets)