Generating a private key I can trust

Given last weeks news about the state of cryptography and the influence of the NSA on standards I decided to enter paranoid/tinfoil-hat mode. The result is that I do no longer consider my asymmetric keys as long enough. So I need to regenerate them. This should be an easy task, but I’m in paranoid mode.

The big problem is “can I trust my systems to generate a safe key”? I decided no, I cannot. Not without investing some time. Normally I would trust my distribution, but I had once to regenerate my SSH key because they got random numbers wrong:
Random Number by Randall Munroe (Creative Commons Attribution-NonCommercial 2.5 License)

So whom do I actually trust? This list is short: the Linux kernel (Linus tree) and FSF/GNU.

Whom do I not trust? That gets more complicated. First of all I do not trust any hardware. It’s impossible to verify that the hardware doesn’t have a backdoor and randomness looks random even if tampered with.

Of course I do not trust the US and any US-based company or company which has interactions with the US. As we had to learn the NSA is putting backdoors into products of US companies and the companies are not allowed to talk about it. This means I do not trust the Linux kernel of any distribution placed in the US or relations with the US. Obviously I extend this on all distributions of companies based in other spy countries (e.g. Five Eyes). This makes the list rather short.

I also do not trust binaries as there is no way to ensure that the binary reflects the source code of the package[1]. This further reduces the list. I’m basically left with Linux From Scratch or Gentoo – two distributions I do not have any experience with. Or use a binary distribution and create the required packages by myself (Linux kernel, GPG). Obviously there is still the risk of a tampered compiler but I consider this risk as rather academic.

Last but not least I do not trust my systems and myself. If I keep the key on the hard disk the security is basically reduced to the strength of the chosen passphrase. Hard disk encryption can add some security to it, but I prefer to have my system in suspend so the key might be in memory and there is always the risk of cold boot attacks. In summary I do not think that hard disk encryption is a solution for protecting the key. Also there is always the risk of an application attacking the system. Getting passphrase through an X11 keyboard logger is unfortunately trivial.

A solution to this problem is getting the key on an external dedicated device. But this is of course conflicting with my “I do not trust hardware” requirement. If hardware random number generators are involved in creating the keys or doing the encryption this would be problematic.

The requirement would therefore be a hardware device which keeps the key secure but does not generate it and is not involved in the session encryption. Today I ordered an OpenPGP Smartcard. This fulfills most of my requirements. It’s trusted by FSFE (Fellowship card), developed by a company which also develops GnuPG and is Germany based. Still I do not trust hardware, but one can upload an externally created key.

So sometime soon I will blog the public key of my new key pair.

[1] I am aware that bitcoin is experimenting in that direction. But this doesn’t help me with the problem to verify the Linux kernel.

41 thoughts on “Generating a private key I can trust

  1. Ye, this does sound paranoic :)
    Do you think you have such important information that you have to go to the extreme?
    I had a period like this a few years ago, configured my Linux machine to be very restrictive… One source(I had many) I was getting instructions from had it categorized to a few modes, “Very High Security Mode” and “Paranoia mode”. I was setting everything like in Paranoia mode :)

    1. Do you think you have such important information that you have to go to the extreme?

      No, but does it matter? After all I have a guaranteed right that ensures that nobody reads my mail. My government is unable to ensure it, so I have to ensure it by myself. If we don’t fight for our rights, we will lose them in the end.

    2. > Do you think you have such important information

      I think everybody has. From your pins (e.g. for your bank account) over the login-passwords you use (e.g. for your mails, your KDE git/svn account, etc) to tons of private stuff you wouldn’t post on your public facebook (for the case you are in that social striptease thing). All the examples named above are confirmed to be collected.

      No, that’s not paranoid. Unfortunately this is the minimum required to keep a little of your privacy. Don’t forget that keeping privacy isn’t only about you. Its also about anyone around you, like your family and friends, who may share things with you but not with the general public. And its damn important for anything you do in your professional life. You may have signed NDA’s and have a responsibility to protect certain customers or your own company secrets. You may got access to infrastructure (e.g. KDE ssh-account) which is not supposed to be public. Its your duty to value the trust others have in you. Don’t stamp that as paranoid. Not in this times.

      1. > I think everybody has.
        But not *everything* needs the same level of paranoia. For example, details of my personal life do not even land on the Internet. OTOH, my academic work has less need for privacy protection.

    3. > Ye, this does sound paranoic :)
      Cryptography implies that. Those who’re not paranoid just cant use it properly, not to menton designing something new. Because its delicate: even one small mistake can lead to chaos. Good example is Debian vs OpenSSL, where a lot of people had to rekey machines.

    4. If the NSA has backdoors available, that means everyone has them.
      I think having paranoia over private informaion is justified.

      Here’s the thing… It’s my data. Even if it’s not important, it’s mine.
      If the US government had data, even if it’s not important, they would persecute and destroy the life of the person that accesssed it.

      I’d like to do the same to the US government.
      Second best, I’d like to encrypt my information so that at the least they cant access it.

      Additionally, my laptop contains government secret documents (not US).
      There is no protection for this data… unless I’m paranoid

  2. Do you trust linux ?
    Where does Linus live ? And the major commiters of the linux kernel?
    A false sense of security.

  3. > First of all I do not trust any hardware.

    Then you should give up now. If you do not trust “any” hardware, then you do not trust your CPU to actually correctly execute a random number generation routine. You do not trust your memory system hardware not to tamper with the results of executing the random number generation routine. You do not trust your motherboard chipset not to tamper with the results of any random number generation routine.

    Basically, if you don’t trust the hardware, you simply can not use it for anything, much less for secure key generation.

    1. how should a CPU know that it is just generating a random key? I meant I do not trust hardware random number generators.

      1. It doesn’t matter if the CPU knows what the purpose of its random number generation is. A PRNG can still be subverted and meaningful data can be extracted from that. See the Dual_EC_DRBG situation for an example.

        You’re being insufficiently paranoid for real security and overly paranoid for the general case.

    2. > Basically, if you don’t trust the hardware, you simply can not use it for
      > anything, much less for secure key generation.
      That’s where things getting interesting. In fact its too complicated to put too smart algorithms into hardware. So you can expect hardware to be “relatively dumb”, failing to figure out it’s “your randomness routine” rather than other, less valuable code or even hardware testing routine which would uncloak “buggy” hardware. And it’s not like if IC vendor would like idea to replace all ICs like Intel had to do once, after some bug jas been found.

      …but there is one thing which not just could be smart. It can behave. And misbehave. I’m about BMCs, the Baseboard Management Controllers and somesuch. This convenience remote control thingie (AMT/vPro) is in fact could be a real backdoor. Firmware, unlike pure hardware, could be smart enough and haves access to network and can watch traffic. There is no way software can intercept or disable it. Then BMC haves access to main system memory and can do whatever, like hacking OS image in RAM or stealing the keys, if desired. And it’s always powered on as it uses standby supply. This is what allows admins to switch PC on and off remotely. Furthermore, when you “disable” BMC on motherboard, it does not really completely switches off BMC. It just tells BMC firmware to no longer respond on remote conrtol features. There is no way to completely switch off BMC, same firmware also often controls cooler rotattion speed, etc. The result? Should BMC firmware decide to do some nasty trick, good luck to prevent it. And of course it lacks source code. So you can’t trust it at all.

  4. Which distro do you use? You say you’re left with Gentoo/LFS for source distros, but Arch Linux (which I use) is an excellent compromise letting you compile anything you want, but have access to binary packages as well.

    1. I’m using Debian. True Arch could be a compromise, though I also don’t have any experience with it. But could be an interesting experience anyway. Will think about it.

  5. If a source-based rolling-release distro is interesting for you, you are welcome to join Exherbo. ;)

    In contrast to most distributions, we have the politic to keep packages as close to upstream as possible, which I think is one of the best ways to avoid issues. ;)
    (Basically that means as few patches as possible, i.e. only if they were already integrated upstream or if there is a very good reason to integrate the patch.)

    Apart from that, if you’re paranoid, I guess it’s mandatory to fetch the linux kernel via git and compile it from source. As that is most probably the easiest way to introduce backdoors.
    In any case, there is no guarantee that it’s not compromised.

  6. BTW, is there some thought about increasing security for wayland based systems against keyloggers and similar tools?

    Apart from that, I think that there are some parts in the linux desktop that need a thought about security. I.e. the keyring/kwallet stuff. Basically any application could say it is application X and wants to access the store. If it’s well done, an application might trick the user to get access to his passwords. I know that there were some thoughts about app signatures and similar, but nothing serious yet, afaik.

  7. One option for a “trusted” option would be to grab a microcontroller. The newer atmegas have an integrated usb driver.

    Put the uc on a pcb with a button and a male usb connector. Register the device as a usb keyboard and have it type out the private key when the button is pressed. For added security you could add a set of switches and require them to be in a certain position before it can type the key out.

      1. yes on X11 that would still allow a keylogger to catch the input – even worse it would be the key and not the passphrase. Though it should be possible to adjust the setup to not act as a keyboard.

  8. This makes sense:

    > I decided to enter paranoid/tinfoil-hat mode.

    And this makes sense:

    > I consider this risk as rather academic.

    But they do not make sense together. If you are in paranoid mode, then all academic risks are taken seriously.

  9. Provide your own random data, and generate your key on a (trusted) system that can not be trivially traced back to you – so even if someone would find the random data in some discarded blocks on disk or in memory, they wouldn’t be able to guess its relation to your key.

  10. > One option for a “trusted” option would be to grab a microcontroller. The newer atmegas have an integrated usb driver.

    And what if hardware trojan embedded in AVR mc by NSA wil communicate over usb with hardware trojans in PC? :)

    It is better to solder device with AVR MCU that will generate keys and store them in OpenPGP card, and random can be entered manually using buttons based on dice output

  11. I agree that you can trust Linus and the FSF, but can you trust Linux and (even more to the point) GnuPG? It’s an argument from authority fallacy.

    Anyways a card does make a lot of sense. Creating privacy that originates in a physical object that you keep on your person gives you some assurance that if your privacy is compromised you will know about it. But again these days I’m not so sure about the encryption itself. We know the NSA is decrypting on-the-wire and maybe it is purely through their access to private certificates, but maybe not.

    1. but can you trust Linux and (even more to the point) GnuPG? It’s an argument from authority fallacy.

      As a friend of mine stated: you cannot trust, but sometimes you have to. If I do not trust Linux and GnuPG and don’t even have to start thinking about crypto. So saying I trust them is more that I trust them by definition.

  12. If you considering changing distribution, you should try using Gentoo or Funtoo (gentoo based, initiated by Gentoo project leader), for compromise you can try Sabayon (Gentoo based binary distribution, but you can still use portage).
    Personally I using pure Gentoo, and with ccache (and distcc for laptop) compilation isn’t burdensome.

    From user perspective, Gentoo have many addicting features excellent for developers (for example in default install: colors in bash’s PS1, completion from history under keys PgUP/PgDn)

    I think best is, that you have control what is going on in your system (you manually adding services to yours boot-levels (I hate when debian do it automatically)) so nothing enable itself behind your back. Another security advantage is automatic QA for every compiled package, so you know, where can be buggy code, and of course GLSA.

    This of course not protect you form NSA, but can keep in mind that many every country have spies, but not in that advanced state.

  13. > So whom do I actually trust? This list is short: the Linux kernel (Linus tree) and FSF/GNU.

    Short?? The Linux kernel has thousands of contributors!
    Given that its use is becoming more and more widespread (Android) as someone already said, the NSA could easily pay one kernel contributors to work on the kernel full time and occasionally send an ‘honest mistake’ patch..

    1. my trust is in the maintainers of the respective sub modules. I do trust them to do a proper review of patches which are security relevant. Yes of course the Linux kernel has vulnerabilities, but that there are some to tamper with the randomness or that one is attackable from the Internet is very unlikely (and for the latter one I have a firewall). Local vulnerabilities do not matter to me as I’m the only user. And if one has broke into my house to get to local vulnerabilities: it’s easier than that, my workstation is basically not protected and live system USB sticks are on my desk.

  14. You trust Linux? Are you nuts? The sheer amount of code size makes it incredibly probable for someone to have put a backdoor there. Of course it is sensible to trust Linux more than Windows but still … :-) You get the point. Happy paranoia Martin! :-)

  15. Hello Martin,
    Thanks for your post. Just a simple question. Why dont you join the Fellowship of FSFE ? By doing so you will receive a smart card for free.

    1. That’s a rather expensive card if I calculate the costs of the Fellowship of FSFE against it. If I would want to be a member I would be one, wouldn’t I?

  16. Oups ! I thought that the minimum contribution was 5 euros per year.
    I found afterward that the minimum was 60 euros, it is indeed rather expensive.
    You can forget my question.

    1. no problem. Yes if it were just 5 EUR I would be a member. Though given that one can get tax deduction I might reconsider. Always thought that’s not possible, just rechecked and noticed it’s possible.

Comments are closed.