On 9/09/2013 2:18 AM, Volker Birk wrote: > On Sun, Sep 08, 2013 at 12:55:05PM -0300, Henrique de Moraes Holschuh wrote: >> Note that even the internal errata/fix information is bound to be really >> uninteresting anyway. Backdoors would not be documented anywhere, heck, it >> is very likely that only the one or two engineers that had to implement them >> even know about it. > > Next problem: security is about trusting other people. If you don't > trust Intel or AMD, better don't use their products. > > I see a lot of things which are destroyed now – it is not only the > “cloud”. This game is over anyways. It's about the base we're all > standing on. The US government and the NSA are eliminating that, and > nothing less. > > If we cannot trust in the manufacturers of the CPUs, we don't have > computers any more we can use. This is absolutely a problem, I have no doubt that the NSA has hooks in as well as requirements to hinder user security. This article [2], points to the "Intel Secure Key" technology [3] (in newer Intel CPUs). The first intro line of the Intel link says: "Intel Secure Key, was previously code-named Bull Mountain Technology." The NYT article [0] mentions "Bullrun" as a program , that neatly fits with "Bull Mountain Technology" .... So, if we have a new enough [later I7?, 3rd gen or later] Intel CPU, then chances are that the random number generator will bring in issues that will interfere with the security of GPG when generating keys, due to NSA "requirements". And here is a quote about /dev/random ..... (from another mailing list that I participate on): "I'm glad Ted Ts'o also understands the need to avoid opaque instruction sets that can't be independently audited, and has resisted pressure from Intel engineers to allow /dev/random to rely solely on the RDRAND instruction." You can't trust the random number generator in Intel CPUs, the special function. If crypto key generation relies on proper random number generation, then crypto is busted ... just ask CryptoCat what happens when there is a flaw in random number generation [4], since fixed by the way. So, all in all, I can see how /any/ microcode update could be the result of NSA requirements and it throws a whole can of worms on trust, particularly with ANY business that is US based or has links to US based companies which may exert pressure to force issues. Furthermore, do we update microcode for older CPUs and potentially allow them to /own/ us too? Do we only use CPUs that pre-date this issue? There are loads of questions, what hope do we have? And this [5] is something that I'll probably end up using to harden my GPG keys..... [0] http://www.nytimes.com/2013/09/06/us/nsa-foils-much-internet-encryption.html?_r=1&; [1] http://www.theguardian.com/world/interactive/2013/sep/05/nsa-project-bullrun-classification-guide [2] http://blog.cryptographyengineering.com/2013/09/on-nsa.html [3] http://software.intel.com/en-us/blogs/2012/05/14/what-is-intelr-secure-key-technology [4] http://tobtu.com/decryptocat.php https://duckduckgo.com/?q=cryptocat%20random%20number%20issue (for more links....) [5] http://gagravarr.livejournal.com/137173.html?nojs=1 (Creating a 8192 bit GPG key to replace my 1024 bit one) Cheers AndrewM
Attachment:
signature.asc
Description: OpenPGP digital signature