If NitrokeyApp and OpenSC is used in Linux for Nitrokey initialization then
can Nitrokey still be used in OpenBSD for non-extractable SSH and GPG keys somehow?
Is there any software support in OpenBSD for Nitrokey Pro2?
It would be nice to combine NitrokeyPro2 with other devices like Nitrokey FIDO2 and even local post quantum key to generate a single hybrid (multiple factored) SSH session key. Modern SSH can support several different key pairs for a single session now by using:
According to Damien Miller (SSH developer):
this is pretty much possible now, by enabling the experimental support
for the XMSS PQ signature algorithm, specifying
AuthenicationMethods=publickey,publickey,publickey,publickey
and by setting the required public keys in authorized_keys.
Even post quantum algos can be combined with more established algos in hardware keys.
Another problem:
There’s no possibility of MITM for ssh clients that have learned the
host’s public key outside of a weakness in the host key signature
algorithm.
If the client is connecting for the first time and does not know the
server’s host key then MITM is trivial.
In a situation of MITM, it is not possible to steal use of the client’s
private keys for authentication against a real destination host unless
the client has forwarded their authentication agent.
I’m not sure what you mean here. If a server has its key compromised,
then it can be trivially MITMd.
It is not obvious for me, if server key is leaked then will the client notice a change of the fingerprint of the server key? Can fingerprint of the server key be forged if server’s private key is leaked?
Does your HSM help to keep server key? Does it work on OpenBSD? How does it work without manual pin-codes or other interaction? Why there are so few HSMs on the market? Actually I could not find any competitors except more advanced (and expensive) PCI express models from Utimaco.com, they have even post quantum models.
Hi!
We do not support directly the builds for the OpenBSD (by testing them locally), but I think it should work straight-away. For the Nitrokey App it was reported to work on FreeBSD: Using the Nitrokey-App under FreeBSD.
I have found some build for *BSD, but I do not know whether this work for you due to lack of experience with this OSes.
It is based on the public/private keys authentication. Please look details in the proper literature, or the OpenSSH documentation. Briefly:
It is not possible determine where one connects the first time without confirming the fingerprint of the public key from another source (e.g. read from the webservice website). Then the fingerprint is stored locally;
If the public key will change on the subsequent connections, one will know its a wrong/phony server.
If the private key leaks, then anyone can act as a trusted party.
About HSM competitors and the market, not thinking too long I guess this is niche, which does not give great return for the investment at the moment (a lot of research, verification and testing). And once the product fails on the market, the company might go out of business due to black PR, so big risk as well. Encrypted communication is just started to being widespread too (the TLS/https to all sites was added just recently - last years).
In generic: you don’t need OpenSC to use gpg or ssh on *BSD. E.g. “ssh-pkcs11-helper first appeared in OpenBSD 4.7” which will make the connection to your token. Also gpg brings there own ssh/token agent in the package.
It depends a bit , what you want to do with the NK token on your OpenBSD system?
NK HSM on a server is -easy spoken- similar as a NK pro on a workplace computer. While the NK pro is driven by a single user ( and that user needs to take care for the token) With NK HSM , the token is on the server and stores the keys there for every user working on it) So you will need a dump terminal connection to the server and then could start there an ssh to a foreign HW.
Using FIDO2 as a second keypair seems for me IMHO Already a bit over-kill. Already the private key of the NK pro will never leave that HW.So why a second key ?
Just for keeping and using SSH and GPG keys unexportable in the Nitrokey device.
I am not sure how can I initialize HSM completely remotely and securely at the same time without SSH.
How can I terminal into server remotely without HSM been already initialized?
Does HSM require a pin on the server to start working with SSH server e.g.?
If so then can typing pin be automated with some program like “expect” to allow the server being initialized automatically just after rebooting?
IMHO the more hybrid keys the better, I would prefer also a key device supporting post quantum algo, but there is no an affordable one, only expensive like utimaco.com.
Are there any ready projects on github to for an easy configuration of a single board as a pkcs11 device?
Is it already possible to use some post quantum algo on a dedicated single board SoC shared and visible by USB the same way as Nitrokey is (via pkcs11 protocol)?
Can you please also suggest a good method of keeping private key secure on a hosted VPS like Linode?
There are some networked HSM but I do not understand at all how they work in terms of being secure without local connection.
How can I start SSH server in a Linode VPS and be sure the assymetric key was never present in the VM RAM? Linode admins can scan and read out SSH sessions keys like one time AES (different each time for each new session), but how to protect permanent assymetric private keys from them?
I am not sure how can I initialize HSM completely remotely and securely at the same time without SSH.
How can I terminal into server remotely without HSM been already initialized?
Does HSM require a pin on the server to start working with SSH server e.g.?
If so then can typing pin be automated with some program like “expect” to allow the server being initialized automatically just after rebooting?
Hmm, you need to understand how ssh and the NK’s working: the NK’s protect “only” the private key inside them. So the private key is , where these NK’s are connected. SSH needs the private key on the machine, where you start your ssh command ! the ssh-agent could forward the the path to the private key also on remote machines, but the key always stays on the machine , where you start your ssh command.
So the NK HSM could only be used local on a server for ssh or gpg. That means you will need a hard-wired terminal to be connected to the server and then you could initiate the ssh connection from the server with the private keys inside the HSM. And of course you could use HSM Keys to do GPG/PGP.
And a HSM typical stores not only the keys for only one user, more for all users on that server ( and the host keys for that server) . You could also use a HSM to secure/backup keys for other systems.
A NK Pro or a FIDO is a single user hw key. With that you will initiate a ssh session to a server that is not hard-wired to your “pseudo terminal”. If you load your private key into the ssh-agent, then you could hop on from the server to a next computer and the agent will forward challenges etc (ssh protocol) to your local pseudo terminal/computer for answering.
If you want to use multiple keys, they all will be handled local to the system to which they are physical connected. So you also could use a HSM on your laptop and use multiple keys out of that HSM to open a ssh connection to a server. or you configure ssh to use different HSM keys for different servers. But for a single person IMHO using two or more HW authentication methods are longterm nasty. It is a different discussion if e.g. the ssh connection to a SAP ERP is only allowed when two people are in the same room. So two HW keys are needed to allow access to e.g. manipulate financial data etc.
If I understood correctly to avoid MITM and key leakage both server and client computer must keep their private SSH keys in hardware Nitro devices.
If I connect to a server and its private key is located in its file system instead of Nitro then I already cannot be sure it is actually my host anymore because it may be a MITMed fake.
I think key forwarding has nothing to do with this case (it would not help) and I would not use forwarding at all because it is not secure IMHO.
You need to differentiate a host key and a user key. NK HSM could keep both private keys inside them.
NK Pro not as it is a user HW token. So to secure the client and the host system the private ssh keys , you would need on both a NK HSM. In such a setup you would also store your private user ssh key on the NK HSM of the client. GPG would not be supported by the NK HSM. Therefor you would need a NK Pro ( OpenCard).
There are different discussions how secure a ssh-agent is - not my discussion. I am not using it on a highly secure system, so also Intel’s Meltdown Bug is not important for me on my FreeBSD system.
Cannot NK Pro be used to store a single SSH server key too?
The NK Pro can only store three keys, or better one key and three subkeys for GPG. One of these keys you could use with the gpg agent to start ssh sessions. This is transparent to you as the gpg-agen is just configured inside gpg.conf. It will ensure that ssh use the token with pkcs11# lib
Why do I need HSM to store client key (you wrote about two HSMs), why not just only NK Pro for the client?
Once you have a NK HSM for your client, you could use it for multiple purpose. Of course NK will sell you another NK Pro for your ssh client as a user key.
Which hardware would you suggest to run OpenBSD free from Spectre, Meltdown and BLOBs?
LOL , this is a wide area for answering: what performance do you expect, what data will you connect etc. And of course this is not my area of expertise. There are also INTEL proz that don’t have these troubles. To my mind a lot of these errors will be found on Intel proz as everybody is focusing on them. But e.g. Cachelines are also used in other proz to speed up the accesstimes. So I have my doubts that ARM, AMD, PowerPC etc. have not a potential for leakage. It might be not found or - even worst - not published.
If you want to protect e.g. atomic rocket bombs, carry it as a suitecase with no network connection with you - then the proc for encrypting/decrypting is no longer relevant ( exept for performance )
Can NK Pro be used for sshD (server daemon) to keep single server’s private key in amount of ONE (one single key)?
I would like to use only NK Pros (two of them) without HSM, is it possible for both SSH server and client to use a single different NK Pro (total two - one Nitro per each end point) Where is an instruction on how to configure NK Pro for a SSH server side?
I would like to avoid X86 completely, would prefer ARMv7hf free of large BLOBs except BROM and free from speculative, needing it for a communication end point to host SSHD, Mail, Jabber, etc.
I guess something like AllWinner or Olinuxino IMX would work out?
Can NK Pro be used for sshD (server daemon) to keep single server’s private key in amount of ONE (one single key)?
In general, yes ( that would be the host key for ssh) - you need to configure the /etc/ssh/sshd.conf to use the NK Pro. BUT it is not supported and it sounds a bit like using a bicycle to transport a load that is normally carried by a truck.
I would like to use only NK Pros (two of them) without HSM, is it possible for both SSH server and client to use a single different NK Pro (total two - one Nitro per each end point) Where is an instruction on how to configure NK Pro for a SSH server side?
This is now a circle back to the beginning of this thread and it starts to get boring. But yes, you could use only NK Pro’s ( 4 of them ) to secure the host key and one client key on both sides. The recommendation for the Server is still using a NK HSM and for the client one NK Pro ( without securing the clients host key )
There are a lot of dependencies, e.g. the OS etc. Why not using the new product from NK the NitroPad?
There are a lot of dependencies, e.g. the OS etc. Why not using the new product from NK the NitroPad?
NitroPad is just an IBM X86 laptop with a Coreboot, Coreboot is not enough for a true security, it would shall be at least Librebooted to be interesting. Actually even Librebooted X86 is not good enough in terms of security, X86 is a shit compared to ARM or RISC-V from hardware security point of view.
