Report picks holes in the Linux kernel release signing process A report looking into the security of the Linux kernel's release signing process has highlighted a range of areas for improvement, from failing to mandate the use of hardware security keys for authentication to use of static keys for SSH access. The Linux kernel is at the heart of a wealth of modern technology, from embedded …
Honest question. Why is SSH key rotation any better than, say, having to change passwords periodically? Cannot an intruder with one key leverage it to get the next one and keep going?
As for requiring physical interaction to smart cards, has consideration been made to the frequency by which these interactions would be necessary, to probe at the risk of click fatigue resulting in the development of bypasses?
I assume the recommendation to change SSH keys is due to the possibility of brute force attacks if a weakness in DSA (or whatever type of key is being used) is found that reduces its effectively length.
Seems a bit silly though, even if a weakness was found that would allow cracking someone's DSA you'd invest a ton of time and money in the cracking. There are a lot of options if you are willing to invest that much, including the simpler (but more risky as far as jail) breaking into their house and threatening them with a $5 wrench.
Threatening with a $5 wrench is effective in the short term but will be reported within minutes to weeks, at which point the team will take countermeasures.
That's not what most people who are interested in hacking the Linux kernel are after. They want to be an advanced, persistent threat.
Threatening with a $5 wrench is effective in the short term but will be reported within minutes to weeks
Depends on whether there is a credible threat of returning, or visiting their daughter's school. The people using $5 wrenches are going to be prepared for the possibility the victim might consider reporting it.
There are also a range of possibilities between $5 wrench and tens of millions of dollars worth of CPU time to crack an SSH key (which itself still relies finding a weakness in DSA or whatever first)
I mean, sure it is cheap and easy to replace SSH keys on a regular schedule, but that's so far above the low hanging fruit if that's really the biggest potential hole you have exposed you are more secure than anyone else on the planet.
I dont think so, unless you're a lunatic that's using SSH keys for symmetric access.
You could use a shared key to get the public key of the next token, but that is not going to be of help to you.
Using your existing access to the developer machine is going to help get the next key, but having the key only works as long as its accepted by the target server, a new laptop and new key and you're locked out, even if you havnt been noticed (horizontal movement obviously ignored).
Changing passwords means you're reliant on humans to invent new ones, who, we've found, will generate weaker ones or open alternate security holes in the process. The same isn't true for SSH keys as they are machine generated so there is no fatigue going into the process.
It's never much fun to invite independent auditors in who you know will publish their findings openly. The first time you do that, you *know* there's going to be stuff you hadn't seen hauled out into the open, and a certain amount of egg on face as a result.
Much kudos to the folks who chose this approach, and co-operated with it, despite the inevitable findings.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
