Announcement

Collapse
No announcement yet.

Radeon Linux 4.6 + Mesa 11.3 vs. NVIDIA Linux Performance & Perf-Per-Watt

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • #41
    Originally posted by atomsymbol View Post
    The CPU will use the private key to decode bytes encoded by the public key. The decoded bytes aren't accessible by software outside of the decoded block(s). The CPU can read the decoded bytes as code and execute the code.
    This puts a lots of management woes and business risks. Say, it implies each and every program vendors must ask permission of CPU manufacturer to sell each and every copy. This is wildly beyond of "1984" and warrants perfect censorship, huge risks for business if cpu vendor refuses to sign new copies, not to mention it would require to encrypt each and every copy on CPU vendor's side.

    If we assume hardcore DRM is the only goal everyone pursues, it sounds technically possible. Yet, DRM does not brings profits on its own. So it only used as some means to deter pirates. As you could guess, this scheme is crackable as well, and it would be easier than you could imagine.

    E.g. games are large, complicated things. They never assume evil, malicious environment on their own. This means attackers could try to cause failures, subverting execution flow in useful ways. They do not really have to crack encryption to get inside. Say, microcontrollers are running in much better conditions: all memories are on same die, it could even generate all clocks (thwarting "clock glitch" attack), but on-chip oscs have very low accuracy, which is not suitable for most applications - only simplest use cases could use inaccurate but secure on-chip OSC. Microcontrollers also use advanced circuitry to check if power good, so power glitching is also complicated. They do it to prevent erroneous operation when batteries run low, etc. It also partially counters some HW-level attacks as side effect. But still, numerous uCs were cracked and protected content extracted, as long as it has been worth of it. Larger CPUs are inherently more vulnerable things since they depend on plenty of external circuits, so attacker who has got physical access could do a plenty of nasty things and there is no way to avoid it. So it only sounds groundbreaking for those boring PC devs, but hardly something new for embedded, mobile devices and many other things. Then there're countless ways to leak the key, beyond your wildest imagination. If you have idea how CMOS works, just measuring power rail pulses would give attacker pretty good idea on what CPU is doing here and now. This implies one could actually recover encryption key by indirect means. For these reasons high-security CPUs e.g. for smart cards are carefully engineered to resist scanning memory, leaking data via power pulese and so on. Only simplest, slow CPU cores could be like this. Larger CPUs security against local attacks is inherently low to medium at very best. The more complicated some system is, the more unexpected failure modes it would expose. This could and would be exploited by attackers.

    Games will converge to use this scheme to encode their binary code. When the buyer downloads the game, the download client (e.g: Steam client) will read the public key and send it to the server (e.g: Steam server). The server will use the public key to create a unique binary code block that matches the private key stored in the CPU on which the game will be running.
    Then immediate attack I can imagine is:
    - Attacker creates keypair and gives public key to steam, pretending it was cpu key. But it was attacker key instead.
    - Steam encrypts it and attacker gets encrypted binary.
    - Attacker decrypts binary and gets unscrewed version of game and free to do whatever.

    It is possible to thwart this attack by keeping database of keys of all cpus around and rejecting non-existent keys. But it would give CPU vendor truly undesirable powers, like censoring everything and even knocking out undesirable companies. Say, if MS would pay Intel a bit, they could just refuse to sign Valve's programs, so everyone have to bow down to Microsoft instead and Valve could go bankrupt. Funny, isn't it?

    Comment


    • #42
      Originally posted by atomsymbol View Post
      Putting a distinct key (RSA) in each CPU would yield a decentralized system. Cracking a single CPU does not automatically imply cracking other CPUs.
      Except the fact attacker could some arbitrary keypair and pretent it was CPU key. Thwarting this kind of attacks would probably take centralised database bringing enormous levels of censorship & centralized control. What if I launched steam in VM and its vCPU returned my own key?

      Comment


      • #43
        Originally posted by SystemCrasher View Post
        Except the fact attacker could some arbitrary keypair and pretent it was CPU key. Thwarting this kind of attacks would probably take centralised database bringing enormous levels of censorship & centralized control.
        [quote]What if I launched steam in VM and its vCPU returned my own key?[quote]

        Solution: The list of all public keys used in CPUs and generated by AMD/Intel/etc will be public. Steam will check that the public key you submit is in the list.

        The CPU manufacturer does not keep a list of the private keys used in CPUs. The private key is put into the CPU and all other copies of the private key are destroyed right after it is put into the CPU - the private key exists only in the CPU.

        Comment


        • #44
          Originally posted by atomsymbol View Post
          HDCP is a centralized system.
          HDCP is not centralized. HDCP is a system where there are UNIQUE keys in hardware, checked by hardware. Yes there are baroque systems in place to revoke hardware keys to allegedly compromised devices, and the way to obtain keys legally is a pain in the ass even for manufacturers (hence most asian manufacturers simply don't give a fuck).

          HDCP's main weakness was that it was coded like total crap, seriously they caught at least 2 different unencrypted key exchanges, the master key was fucking reverse-engineered, and meanwhile there are large supplies of 30$ boxes that are a valid HDCP target but then hide any device after them (I know because I use them to fix the retarded incompatibility between 1500+$ pieces of equipment just because HDCP version).

          Behind HDCP there is Intel. I doubt that all morons in the company got moved to the HDCP department, so I suspect that it is a choice, making a low-cost "best-effort" attempt at an antipiracy system, that will probably fail horribly, but that will allow them to render obsolete entire lines of hardware.

          For example, with HDCP every 2 years or so now there is a new version that is not retrocompatible. Fun for all law-abiding citizens.

          Putting a distinct key (RSA) in each CPU would yield a decentralized system. Cracking a single CPU does not automatically imply cracking other CPUs.
          You don't need to crack other CPUs, you only need a key or some compromised hardware to decrypt the program once, then it goes on piratebay as usual. Maybe in a wrapper or whatever.

          As a general rule, placing secret keys in hardware is a good way to get them sniffed.

          Comment


          • #45
            Originally posted by starshipeleven View Post
            HDCP is not centralized. ... the master key was reverse-engineered...
            Those two terms form a contradiction.

            Comment


            • #46
              Originally posted by starshipeleven View Post
              You don't need to crack other CPUs, you only need a key or some compromised hardware to decrypt the program once, then it goes on piratebay as usual.
              How are you proposing to read the private key from the middle of a 14 nanometer CPU?

              Comment


              • #47
                Originally posted by atomsymbol View Post
                Those two terms form a contradiction.
                Nope. the master key is the thing used to generate the private keys of the devices, as they didn't use the gargantuan public database of public keys you are talking about.

                Master key allows easy generation of new compatible keys, it's not integral part of the system once out in the wild.

                How are you proposing to read the private key from the middle of a 14 nanometer CPU?
                Probably by exploiting design flaws. All hardware encryption fails due to design flaws.

                Me? I'd focus on stealing batches of keys from the fabs, BEFORE they are written, or crack the master key, as they will use a master key, making a large database with public keys and stuff is annoying and still risky, as from large amount of public keys they can gather something to bust the encryption.
                Last edited by starshipeleven; 05-24-2016, 11:05 AM.

                Comment


                • #48
                  Originally posted by starshipeleven View Post
                  Nope. the master key is the thing used to generate the private keys of the devices, as they didn't use the gargantuan public database of public keys you are talking about.
                  A couple of terabytes is gargantuan? It isn't year 1995 now.

                  Originally posted by starshipeleven View Post
                  Probably by exploiting design flaws. All hardware encryption fails due to design flaws.
                  The evolution of the private key in CPUs will be spread over multiple CPU generations. Successive generations will have smaller number of hardware design flaws.

                  Originally posted by starshipeleven View Post
                  Me? I'd focus on stealing batches of keys from the fabs, BEFORE they are written,
                  AMD/Intel/etc would figure out that the private key needs to be generated by the CPU itself. Only the public key can be read from the CPU.

                  Originally posted by starshipeleven View Post
                  or crack the master key, as they will use a master key,
                  No master key.

                  Originally posted by starshipeleven View Post
                  making a large database with public keys and stuff is annoying and still risky, as from large amount of public keys they can gather something to bust the encryption.
                  One could download a large number of RSA public keys from the internet. Nobody cracked RSA yet.

                  Comment


                  • #49
                    Originally posted by atomsymbol View Post
                    A couple of terabytes is gargantuan? It isn't year 1995 now.
                    Hm, good point.

                    The evolution of the private key in CPUs will be spread over multiple CPU generations. Successive generations will have smaller number of hardware design flaws.
                    Will not matter unless you render obsolete the older and more flawed CPUs, and if you do so, and it happens at any relevant rate (let alone that of HDCP), the most likely outcome is that game/program/whatever designers choose to NOT use it to avoid heavy flak from both users AND companies that don't usually like to change a zillion CPUs just because someone said so.

                    Seriously, MS got this more right. They want to do something like you said, but the TPMs are their thing.
                    TPM can be usually changed (tablets excluded, but who cares anywyay), so in case they need to make non-retrocompatible changes, they can be changed.

                    AMD/Intel/etc would figure out that the private key needs to be generated by the CPU itself. Only the public key can be read from the CPU.
                    Dunno, it needs a lot of entropy, low-entropy means crappy keys. Entropy must come from outside the chip. Which means that my fictional team will not be stealing keys, but hampering the entropy of a batch of CPUs when they are generating the key, possibly even seeding it.

                    No master key.
                    I know my chicken. There is no reason to make it too safe. Must be "best effort".

                    One could download a large number of RSA public keys from the internet. Nobody cracked RSA yet.
                    I thought you were saying there were many public keys for each private key, that would theoretically allow to reverse-engineer the private, the same as the master key of HDCP.

                    Anyway these are an example of the hacks that could be attempted on the CPUs.

                    A cool hack done at a university uses a hiccup in CPU power supply to get it to cough bits of the private key over some time (probably not applicable if this crypto core uses only inaccessible internal registers, this is just an example) http://www.engadget.com/2010/03/09/1...ng-cpu-of-ele/

                    This one is even funnier http://www.rtl-sdr.com/stealing-encr...tic-emissions/
                    radio emissions from the device are used to sniff the (low-level operations the device is doing, leading to sniffing the) keys.
                    Last edited by starshipeleven; 05-24-2016, 03:03 PM.

                    Comment


                    • #50
                      Originally posted by atomsymbol View Post
                      Solution: The list of all public keys used in CPUs and generated by AMD/Intel/etc will be public. Steam will check that the public key you submit is in the list.
                      Still, DB of this scale is subject to all kinds of abuse, ranging from breaching privacy to attempts to deny competitors access to this informatoins either by DoS attacks or via private agreements.

                      The CPU manufacturer does not keep a list of the private keys used in CPUs. The private key is put into the CPU and all other copies of the private key are destroyed right after it is put into the CPU - the private key exists only in the CPU.
                      Realistically, at least some CPU manufacturers would keep private keys. If we take a look on "engineering logins" they often do exactly that.

                      Comment

                      Working...
                      X