Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Secure identities with HSM #949

Open
asbjornenge opened this issue May 22, 2019 · 10 comments
Open

Secure identities with HSM #949

asbjornenge opened this issue May 22, 2019 · 10 comments
Assignees
Labels
Status: Backlog Older issues that are awaiting resolution Type: Feature Request or Suggestion Enhancements, performance concerns, etc.

Comments

@asbjornenge
Copy link
Contributor

Problem

Currently, if a device connected to a Zerotier network is compromised, an attacker will gain access to the entire network and all nodes connected to it will be at risk.

Since identity secrets are stored as a file on disk, they are volunerable to remote theft which increases the likelyhood of an attack.

As ZeroTier gains in popularity and use, theft of identity secrets might become popular and frequent. Given the major downside of loosing these files, it seems appropriate to consider remedies.

Possible solution

By using an HSM (Hardware Secure Module) such as a Yubikey or similar, we can remove the possibility of remote attacks and reduce this risk to the lower probability local theft scenario.

Is it possible and/or feasible to keep zerotier identities on an HSM and only enable ZeroTier networking if the HSM is connected?

Having a ZeroTier identity tied to an HSM will also make the identity conveniently portable wherever you take your HSM.

@paweljacewicz
Copy link

I use GL-USB150 (https://www.gl-inet.com/products/gl-usb150/) microrouter for similar (portability) use case.

@sbilly
Copy link

sbilly commented May 23, 2019

I use GL-USB150 (https://www.gl-inet.com/products/gl-usb150/) microrouter for similar (portability) use case.

You mean that you can keep the key in the microrouter even the computer was compromised?

@asbjornenge
Copy link
Contributor Author

@paweljacewicz thanks for the tip! It's definitely an improvement 👍 However, if your computer is compromised it is also possible to compromise the microrouter remotely via your computer. So not the same level of security I am looking for here.

@paweljacewicz
Copy link

I get your point but if your machine is compromised then it's basically game over in most attack scenarios. Keeping ZT identity on a HSM does not prevent an attacked from pivoting in your network if your machine is compromised (as far as I understand your use case). If you are afraid of this 'identity theft' then you should monitor where your clients connect from to your controller and deauth the abnormal ones.

ZT is pretty much custom crypto (correct me if I'm wrong) and enabling HSM support for identity storage/use would not be easy, if possible at all using standard HSM solutions. Maybe some mid-tier solution, like HSM-supported decrypting of the identity file that's stored on disk (and keeping the decrypted version in memory)? Or some additional authentication factor when ZT daemon starts and contacts the Controller. Either way, custom development.

It's all about risk management. The microrouter solution is just the simplest way, and it can be hacked, like everything else basically. But making it work with ZT took me maybe an hour and I use it as an access stick on-the-go, not replacement of my "normal" ZT client.

Hope you find this helpful and share your thoughts if you find solution to your use case!
Cheers!

@glimberg
Copy link
Contributor

ZT is pretty much custom crypto (correct me if I'm wrong)

ZeroTier is not custom crypto at all. It's Curve25519, Poly1305, and Salsa20.

@paweljacewicz
Copy link

ZT is pretty much custom crypto (correct me if I'm wrong)

ZeroTier is not custom crypto at all. It's Curve25519, Poly1305, and Salsa20.

True, ok. What I meant was custom implementation of the crypto you mentioned above. At least I think it is the case based on some discussions I saw here on github previously (e.g. #811 ).
I'm not against custom coding approach if it works, as it is the case with ZT, but maybe using some more "standard" and adapted libraries would be a better approach, at least for security reasons.

@asbjornenge
Copy link
Contributor Author

asbjornenge commented May 24, 2019

@paweljacewicz My main concern is theft of the identity secret. I don't see a way to get around an attacker having access to the network from a compromised computer while said computer is online - that would hurt usability too much. However, if the secret was stored in an HSM, atleast the attacker could not steal the secret and access the network at will from any device. 🤔

@paweljacewicz
Copy link

@paweljacewicz My main concern is theft of the identity secret. I don't see a way to get around an attacker having access to the network from a compromised computer while said computer is online - that would hurt usability too much.

Proper segmentation and monitoring should help a lot. 2FA for access to critical services.

However, if the secret was stored in an HSM, atleast the attacker could not steal the secret and access the network at will from any device. 🤔

This would definitely limit the scope of possible attacks but you won't find a silver bullet for this kind of threats. If you did a lot of people will be out of work, including me ;)

@asbjornenge
Copy link
Contributor Author

asbjornenge commented May 27, 2019

@paweljacewicz Limiting the scope is exactly what I am looking for 😉

@adamierymenko adamierymenko added Status: Backlog Older issues that are awaiting resolution Security Security issues, code or otherwise labels May 29, 2019
@michaelsmoody
Copy link

I'm on board with this, either HSM or a public/private "signing" mechanism where networks can be cryptographically signed (with a key), meaning that only nodes that can pass this can be joined.

@unquietwiki unquietwiki added the Type: Feature Request or Suggestion Enhancements, performance concerns, etc. label Aug 5, 2020
@someara someara added the P3 label Jan 10, 2024
@someara someara self-assigned this Apr 29, 2024
@someara someara added P2 and removed P3 labels May 9, 2024
@laduke laduke removed the P2 label Oct 9, 2024
@glimberg glimberg removed the Security Security issues, code or otherwise label Oct 22, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Status: Backlog Older issues that are awaiting resolution Type: Feature Request or Suggestion Enhancements, performance concerns, etc.
Projects
None yet
Development

No branches or pull requests

9 participants