Announcement

Collapse
No announcement yet.

Linux 3.14 Supports AMD's Cryptographic Coprocessor

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

  • Linux 3.14 Supports AMD's Cryptographic Coprocessor

    Phoronix: Linux 3.14 Supports AMD's Cryptographic Coprocessor

    The AMD Cryptographic Coprocessor (CCP) is to be supported by the in-development Linux 3.14 kernel...

    http://www.phoronix.com/vr.php?view=MTU4MTM

  • #2
    Is this the type of hardware that Netflix on Linux devices demands (such as the Rokubox and Chromebooks)? Or is that completely different hardware?

    Comment


    • #3
      Originally posted by CTown View Post
      Is this the type of hardware that Netflix on Linux devices demands (such as the Rokubox and Chromebooks)? Or is that completely different hardware?
      Nuuuuuu. This is about offloading Crypto-based calls to a dedicated piece of hardware so that it isn't clogging up the main processor. Its a pretty common practice amongst ARM devices as far as I can tell, since they aren't as powerful as x86. They'll have the main ARM CPU for the main stuff, and then dedicated pieces of hardware for video decoding (and now crypto), since they are dedicated they can optimized for that ONE task and be able to do it faster and with using less power.

      Comment


      • #4
        Damn American NSA to hell!

        How can closed pieces of silicon be trusted to calculate crypto functions correctly without any degradation in security these days? It's not like you can open up the code for them and verify what's inside... And you can no longer trust any of the manufacturers, if they are USA or Chinese corporations, or do lots of business in these countries.

        And minor and hard to detect "bugs" in crypto calculations can be implemented to reduce the security massively, and these can go undetected for years...

        Ok, AVX optimizations are actually good and useful since they are used for many many things and would break other things if they are buggy. But complete crypto specific implementations in silicon cannot be fully trusted...

        --Coder

        Comment


        • #5
          Originally posted by coder111 View Post
          How can closed pieces of silicon be trusted to calculate crypto functions correctly without any degradation in security these days?
          For an encryption algorithm, very easily. Generate a bunch of random data, encrypt it first using a known-good software algorithm, then run it through the hardware module and compare the results.

          With a hardware true random number generator on the other hand, it's harder to prove that its output gives truly random number. That said, they measure EM noise in the environment so they're quite likely to be far more secure than any software PRNG.

          Comment


          • #6
            Originally posted by coder111 View Post
            How can closed pieces of silicon be trusted to calculate crypto functions correctly without any degradation in security these days? It's not like you can open up the code for them and verify what's inside... And you can no longer trust any of the manufacturers, if they are USA or Chinese corporations, or do lots of business in these countries.

            And minor and hard to detect "bugs" in crypto calculations can be implemented to reduce the security massively, and these can go undetected for years...

            Ok, AVX optimizations are actually good and useful since they are used for many many things and would break other things if they are buggy. But complete crypto specific implementations in silicon cannot be fully trusted...

            --Coder
            Linux doesn't get random numbers from one source, it uses many sources at the same time and mixes it in a random ratio too.

            Comment


            • #7
              Originally posted by ricequackers
              For an encryption algorithm, very easily. Generate a bunch of random data, encrypt it first using a known-good software algorithm, then run it through the hardware module and compare the results.
              Assuming that you control all of the inputs to both algorithms (i.e. neither rely in any part of system state that is not known or deterministic, like a hardware entropy generator that you mention later), then yes, it is possible to manually verify that output for every possible input. Depending on how computationally intensive the algorithm is and on the number of inputs, it might take a while though.

              Originally posted by ricequackers
              With a hardware true random number generator on the other hand, it's harder to prove that its output gives truly random number. That said, they measure EM noise in the environment so they're quite likely to be far more secure than any software PRNG.
              Actually, it's really hard to prove that EM noise is random. Some of the EM noise will be coming from the processor itself and some will come from various components on the system. Some EM noise could also be coming from the environment. It would probably look quite random, but cryptographically useful randomness has certain restrictions and mathematical properties that are difficult or even impossible to prove for EM noise in an un-known environment. Relying entirely on EM noise would potentially open you up to side-channel attacks. It would also open you up to minor variances in manufacturing process that might lower entropy by slightly modifying whatever mechanism generates the entropy. Shaving off a few too many atoms on one side might alter the probability of getting values in a certain range, and expose you to attacks by making it much easier to guess what the inputs to the encryption algorithm are. Doing so would also make it almost impossible for even the hardware manufacturer to know if there are flaws, let alone whether or not those flaws are due to tampering by government or private entities. As manufacturing processes get even smaller, the risk here will only increase.

              In short, cryptography is complicated.

              Comment


              • #8
                Any AMD dev to the rescue?

                Does anybody have infos on that? Bring light into darkness?

                As far as I understood Kaveri (and maybe Kabini??) as well as future APUs feature an embedded ARM CPU inside the APU.

                Can I imagine this as a kind of extended "padlock engine" like VIA had (or the AMD Geode LX)?
                Does it also fall in the HSA area?
                Is this a closed hardware blob inside the APU or can Linux kernels (and thus the user/land) make use of it for doing fancy things like crypto acceleration (esp. on smaller CPUs), HW-RNGs, ...?
                Could it be also used in future as a power supervisor, like sending x86 cores to sleep when not in use and stay awake - using only a few mW - to wake up x86 cores when needed?
                Is the "Trust Zone" trustable? Or does ARM have to trust me (like in TCPA / TPM where the user is generally suspected to use unlicensed software or something...)?
                What are the benefits for the user? What are the benefits for AMD to place such a unit inside the x86?
                Stop TCPA, stupid software patents and corrupt politicians!

                Comment


                • #9
                  Is TrustZone trustable?
                  Just like SecureBoot, it may or may not. If the system ships with it locked, it's used against you and you can't do a thing. There are systems using it for DRM.

                  Comment


                  • #10
                    Originally posted by phoronix View Post
                    Not much information is publicly known on this AMD Cryptographic Coprocessor but it's believed to be part of AMD's embedded ARM Cortex-A5 processor on upcoming server-class Opterons with TrustZone technology.
                    The first CPUs/APUs featuring the "AMD Security processor" will be Beema/Mullins (image link from here).

                    Comment

                    Working...
                    X