Page 1 of 2 12 LastLast
Results 1 to 10 of 11

Thread: Linux 3.14 Supports AMD's Cryptographic Coprocessor

  1. #1
    Join Date
    Jan 2007
    Posts
    13,415

    Default 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. #2
    Join Date
    Sep 2011
    Posts
    71

    Default

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

  3. #3
    Join Date
    Aug 2012
    Location
    Pennsylvania, United States
    Posts
    1,747

    Default

    Quote 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.

  4. #4
    Join Date
    Oct 2012
    Posts
    25

    Angry 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

  5. #5
    Join Date
    Dec 2013
    Posts
    24

    Default

    Quote 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.

  6. #6
    Join Date
    Jul 2013
    Posts
    33

    Default

    Quote 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.

  7. #7
    Join Date
    Jan 2014
    Posts
    1

    Default

    Quote 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.

    Quote 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.

  8. #8
    Join Date
    Mar 2009
    Location
    in front of my box :p
    Posts
    733

    Default

    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?

  9. #9
    Join Date
    Feb 2008
    Location
    Linuxland
    Posts
    4,729

    Default

    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.

  10. #10
    Join Date
    Mar 2008
    Posts
    63

    Default

    Quote 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).

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •