Linux Kernel Git Repositories Add 2-Factor Authentication

LibbyMC writes For a few years now Linux kernel developers have followed a fairly strict authentication policy for those who commit directly to the git repositories housing the Linux kernel. Each is issued their own ssh private key, which then becomes the sole way for them to push code changes to the git repositories hosted at kernel.org. While using ssh keys is much more secure than just passwords, there are still a number of ways for ssh private keys to fall into malicious hands. So they've further tightened access requirements with two-factor authentication using yubikeys.

Comments

Oh no.

[i kan reed]

Someone might commit code to our open source project. We can't have that.

Re:Oh no.

[i kan reed]

Okay, so once again I have to be reminded that no one is allowed to joke about the Linux kernel, because the distros are responsible for packaging a sense of humor.

Re:Oh no.

[i kan reed]

As long as we're being humorless assholes:
Jokes are defined by the intention of humor. Lots of things are funny that aren't jokes, like, say, if you died, it'd be hilarious. Lots of things are jokes that fail at being funny: see the complete works of Carlos Mencia.

Finally as secure as MMO games

[Zan Lynx]

Finally the Linux kernel which runs almost the entire Internet is as secure as my MMORPG accounts. About time. :P

Re:How does it work without a clock?

[ChadL]

I have a Yubikey that I use for encrypting my password stores (using the private id as one of several components passed to a pbkdf). It detects replays by verifying that every token has a larger counter then all prior used tokens (and the timer depending on the application).
A Yubikey token looks like 'ficrtvulktgnerhddigbhcudufurijghfcckvchhjfli' and is a modhex (16 chars picked for being the same across charsets) and contains the following:
1) A public ID to identify the key
2) AES128 encrypted 128 bits containing the following:
a. Secret ID
b. Insertion counter (how many times its been plugged into a computer)
c. Token counter (within one insertion)
d. Timestamp (A counter counting the time since the token was inserted into the computer)
e. Random number
f. Checksum of the above
Their website has full specifications and documentation.

Re:Malware

[Zero__Kelvin]

"Well, malware injection to the linux kernel isn't a mere possibility. The incident that happened back in late 2003 comes to mind."

I don't think you are intentionally trying to misrepresent the facts, but before others take the misrepresentation of the facts and run with it ...

"But this attack never had any chance of corrupting the mainline kernel. The CVS repository is generated from BitKeeper, it is not a path for patches to get into the BitKeeper repositories. So the code in question could only affect users who were working from the CVS repository. Kernels used by distributors probably do not come from that repository, and, as this incident has shown, illicit code can only remain there for so long before being detected."

I think you are confusing a failed attempt with a successful injection. The checks and balances in place stopped it sans two-factor auth. This just makes it even more unlikely.

Re:How does it work without a clock?

[jcochran]

Well, you could have answered your own question by simply using google to look up Yubikey and reading a bit. But to give you a partial answer, the token generates an AES encrypted value and passes that value to the server for authentication. During authentication, the server decrypts the value. (the shared secret between the token and the server is the AES encryption key). The decrypted value includes a counter. And if the counter isn't greater than the previously used counter, the authentication attempt is invalid. So if you were to hit the button 100 times and record those codes, you could authenticate using any of those codes, but as soon as I hit the button and authenticated using the resulting code, all of the codes you recorded would become instantly invalid.

Re:How does it work without a clock?

[Mr_Icon]

Yubikeys also support the HOTP standard, which produces 6-digit codes. This is what kernel.org actually uses, not yubikey's own implementation.

keys are not issued to someone they are generated

[tota]

The user is not issued a key, he generates one and gives it to the repository administrator to get ssh access. This process is called *generating* a key, and you can publish the public key to anyone, including the repository administrator which will then use it to grant you access. The private key however.. should remain private.

The point is that only *you* should ever have access to the private key, having someone else generate it (as is suggested by the wording in this article) would be very unusual, as you would not want to use this key for anything else, and someone else would have your private key for no good reason. Someone could even potentially use this key to fake your identity in commits.

The problematic wording is here: "Each is issued their own ssh private key".