On June 21, 2019, support for SSH key shielding was introduced into the OpenBSD tree, from which the OpenSSH releases are derived. SSH key shielding is a measure intended to protect private keys in RAM against attacks that abuse bugs in speculative execution that current CPUs exhibit.[0] This functionality has been part of OpenSSH since the 8.1 release. SSH private keys are now being held in memory in a shielded form; keys are only unshielded when they are used and re‐shielded as soon as they are no longer in active use. When a key is shielded, it is encrypted in memory with AES‐256‐CTR; this is how it works: [...]
https://xorhash.gitlab.io/xhblog/0010.html
Related Stories
OpenBSD user Lari Huttunen has a blog post in which he dives into using OpenBSD's rdomain(4) feature to sort work VPNs into separate kernel-level routing tables. This segregates the network traffic in such a way as to prevent traffic in separate routing tables from interacting. With many working from home, insecure work networks have begun to intrude into the home LANs via work-related VPNs. By adding the home network to a work VPN, the LAN becomes merged with work's internal network, usually quite insecure at that. His goal is to keep his personal home devices, especially the IoT items, separate from the now mandatory work-related VPNs on his small-office / home-office network. That way, the work networks can no longer access his appliances.
Problem Statement
Over the years, companies and corporations have become ever more hungry for everything related to their users' geolocation, telemetry, demography, relationsip with one another, interests, convictions, social preferences - you name it. At the same time, users wanting to consume digital services meet a lot of ridiculous restrictions depending on where they live and how they access the Internet. Ecojails, in one form or another are created by multi-national corporations in order to capitalize everything about their users' behavior. In 2020, this has all been exacerbated by everyone suddenly working from home if possible.
Motivation
This is why I wanted to research how identity-based routing could enhance users' privacy in a totally transparent way. I've never been a big fan of VPNs as a security solution, but have come to realize that they have a role to play in privacy. Since soon everything needs to be online to function from a vacuum cleaner to dish washer to toaster, it is increasingly difficult to keep the Internet of Targets at bay. Moreover, our personal telemetry devices feed out a constant stream of information to the ecojail masters, be they Apple, Google, Microsoft, Amazon, Alibaba or Netflix. Taking back control will not be easy and one will evidently need to compromise along the way, but realization is the first step to recovery.
Lari's solution works from tools provided by OpenBSD's base system.
Previously:
(2020) WireGuard Imported Into OpenBSD
(2019) How SSH Key Shielding Works
(2019) Dutch Govt Explains the Risks Behind DNS-Over-HTTPS Move
(2014) OpenSSH No Longer has to Depend on OpenSSL
SSH key forwarding is to be avoided when possible. When it is not possibile to avoid, it is a good idea to limit what gets forwarded. Software developer Vincent Bernat describes one way by putting a simple shell script wrapper around the SSH client to provide a session with a unique, ephemeral key agent.
ssh-agent is a program to hold in memory the private keys used by SSH for public-key authentication. When the agent is running, ssh forwards to it the signature requests from the server. The agent performs the private key operations and returns the results to ssh. It is useful if you keep your private keys encrypted on disk and you don't want to type the password at each connection. Keeping the agent secure is critical: someone able to communicate with the agent can authenticate on your behalf on remote servers.
ssh also provides the ability to forward the agent to a remote server. From this remote server, you can authenticate to another server using your local agent, without copying your private key on the intermediate server. As stated in the manual page, this is dangerous!
Perhaps another approach would be to embed the wrapper in the ProxyCommand configuration directive, thus obviating the need for either a shell alias or shell function.
How and why have soylentils had to deal with SSH agent forwarding?
Previously:
(2019) How SSH Key Shielding Works
(2019) SSH Gets Protection Against Side Channel Attacks
(2018) Default OpenSSH-Portable RSA Private Key Encryption is Poor
(2017) SSH vs OpenVPN for Tunneling
(2016) Upgrade Your SSH Keys
(2015) Why Aren't We Using SSH for Everything?
OpenSSH developer, Damien Miller, has announced plans to remove support for DSA keys from OpenSSH in the near future. His announcement describes the rationale, process, and proposed timeline.
The next release of OpenSSH (due around 2024/03) will make DSA optional at compile time, but still enable it by default. Users and downstream distributors of OpenSSH may use this option to explore the impact of DSA removal in their environments, or to hard-deprecate it early if they desire.
Around 2024/06, a release of OpenSSH will change this compile-time default to disable DSA. It may still be enabled by users/distributors if needed.
Finally, in the first OpenSSH release after 2025/01/01 the DSA code will be removed entirely.
In summary:
2024/01 - this announcement
2024/03 (estimated) - DSA compile-time optional, enabled by default
2024/06 (estimated) - DSA compile-time optional, *disabled* by default
2025/01 (estimated) - DSA is removed from OpenSSH
Very few will notice this change. However, for those few to whom this matters the effects are major.
Previously:
(2021) scp Will Be Replaced With sftp Soon
(2020) SHA-1 to be Disabled in OpenSSH and libssh
(2019) How SSH Key Shielding Works
(2016) Upgrade Your SSH Keys
(2014) OpenSSH No Longer has to Depend on OpenSSL
(Score: 3, Insightful) by VLM on Thursday December 19 2019, @10:48PM (2 children)
Its a good idea although the best application of effort might be putting your keys on the end of a USB connector. Play with the keys in a better spot, not play with the keys in a better way.
I have an use a yubico key for various auth. For some things like Amazon AWS its ridiculously simple to set up and even require for other users. Other applications somewhat harder.
I'd like to see something like that merged with watch/fitbit in some magical bluetooth manner, or NFC, perhaps. Enter my pin (lame password) by hand, push a button on my watch, away I go.
AFAIK there is no FIDO2, U2F compatible watch out there. I'd even wear a stylish sweatband wrist bracelet if necessary, if a watch would be impossible.
Its actually kinda odd that there's so many novelty flash drive containers but the only FIDO2 U2F key format is little flash drive alike thingies.
(Score: 2) by TheGratefulNet on Friday December 20 2019, @12:36AM
the main idea is to keep things 'encrypted at rest' and only unlock them for the shortest period of time possible.
"It is now safe to switch off your computer."
(Score: 1, Insightful) by Anonymous Coward on Friday December 20 2019, @04:49AM
The problem with that is that compared to this is you'll be prompted for the key whenever the program needs it. For SSH, that would be a maximum of the rekey interval, which defaults to one hour, but could be decidedly less.
(Score: 1, Funny) by Anonymous Coward on Friday December 20 2019, @12:21AM (2 children)
Store your ssh keys using rot13, the NSA hasn't backdoored that yet.
(Score: 0) by Anonymous Coward on Friday December 20 2019, @04:00AM
Even better, do it twice!
(Score: 2) by maxwell demon on Friday December 20 2019, @07:10AM
For better security, do triple-rot13. But remember, the second one must be done in reverse.
The Tao of math: The numbers you can count are not the real numbers.
(Score: 1) by The Vocal Minority on Friday December 20 2019, @03:54AM (3 children)
OK, so, this makes it harder to retrieve the SSH private key from memory because the attacker must slurp a (relatively) massive prekey as well as the encrypted private key?
(Score: 0) by Anonymous Coward on Friday December 20 2019, @10:45AM
Well you have to decrypt to memory at some point just hope they don't look during the milliseconds it is.
(Score: 4, Interesting) by driverless on Friday December 20 2019, @10:58AM (1 child)
Their explanation isn't very good at all. When you use side-channels to try and read a key, you typically get most of the bits and then reconstruct the rest using various mathematical tricks which this margin is too small to contain. By using an avalanche function on 16kb of data with no structure, even one misplaced bit read will result in a completely different key, and since the 16kb is random you can't use any clever tricks to try and reconstruct the incorrect bit(s). It's a clever trick.
Not sure if the returns are worth the effort it requires, but it is a clever trick.
(Score: 1, Funny) by Anonymous Coward on Saturday December 21 2019, @06:04AM
Nice Pierre de Fermat reference there. But the real question is whether that comment is going to spark a mathematical mystery lasting over 350 years.
(Score: 0) by Anonymous Coward on Friday December 20 2019, @01:30PM
do not worry about the computational cost.
they will, again, make CPUs faster with verious tricks ...