31–40 of 56 posts
Very little of this has to do with a PI, it seems like almost any kind of home server would work (especially linux). And it is unclear to me what value is added by the yubikey? And would any FIDO device work, or is this yubikey brand only?
"with a Yubikey" is probably a better title. The yubikey thingy costs more than the PI (and there is a helpful link if you want to buy one). Very little of this has to do with a PI, it seems like almost any kind of home server would work (especially linux). And it is unclear to me what value is added by the yubikey? And would any FIDO device work, or is this yubikey brand only?
Primarily, the YubiKey is there to lock away the private key while making it available to the running CA. Certificate signing happens inside the YubiKey, and the CA private key is not exportable.
This uses the YubiKey PIV application, not FIDO.
As an aside, step-ca supports several approaches for key protection, but the YubiKey is relatively inexpensive.
Another fun approach is to use systemd-creds to help encrypt the CA's private key password inside a TPM 2.0 module and tie it to PCR values, similar to what LUKS or BitLocker can do for auto disk unlocking based on system integrity. The Raspberry Pi doesn't have TPM 2.0 but there are HATs available.
Earlier quoted context omitted.
>How does the disconnected audio input of any random PC or thinclient compare? That will give you RF noise, which isn't really random.
> That will give you RF noise, which isn't really random. what does "really" random even mean in this context? does it actually matter? given 3 hypothetical devices in a homelab: a) does no specialized hardware entropy collection, and instead relies entirely on the standard Linux kernel mechanisms b) does entropy collection based on the RF noise that you're saying isn't "really" random c) does entropy collection base…
https://www.infoq.com/news/2019/12/rsa-iot-vulnerability/
So bad randomness can let a remote attacker break them much more easily.
I'm running smallstep CA in my homelab. While it's nicely done and clearly focuses to the containerized enterprise market, its defaults are very harsh. Take for example the maximum certificate duration. While from a production/security perspective short-lived certificates are great, you don't want to renew certs in your homelab every 24-48hrs. Also, many things just don't support ACME but still benefit from a valid c…
I'm running smallstep CA in my homelab. While it's nicely done and clearly focuses to the containerized enterprise market, its defaults are very harsh. Take for example the maximum certificate duration. While from a production/security perspective short-lived certificates are great, you don't want to renew certs in your homelab every 24-48hrs. Also, many things just don't support ACME but still benefit from a valid c…
It's true, the defaults are quite strict. As for the "hours" max interval, this is the result of a design decision in Go's time duration library, dealing with the quirks of our calendaring system.
This is littered with so many missteps I don't know where to start. -Complete overkill requiring the use of a YubiKey for key storage and external RNG source - what problems does this solve? For a Yubikey to act as a poor man's HSM you have to store the PIN in plaintext on the disk. So if the device is compromised, they can just issue their own certs. If it's to protect against physical theft of the keys, they'll jus…
Hi, I'm the author of the post. Thanks for your questions here. > -Complete overkill requiring the use of a YubiKey for key storage and external RNG source - what problems does this solve? For a Yubikey to act as a poor man's HSM you have to store the PIN in plaintext on the disk. So if the device is compromised, they can just issue their own certs. If it's to protect against physical theft of the keys, they'll just…
This has been on my list to implement for a while. It's a really great idea for things like proxmox and pfsense that you probably don't want to use LetsEncrypt for, but support ACME.
Earlier quoted context omitted.
> That will give you RF noise, which isn't really random. what does "really" random even mean in this context? does it actually matter? given 3 hypothetical devices in a homelab: a) does no specialized hardware entropy collection, and instead relies entirely on the standard Linux kernel mechanisms b) does entropy collection based on the RF noise that you're saying isn't "really" random c) does entropy collection base…
Suitably similar RSA keys well compromise each other. https://www.infoq.com/news/2019/12/rsa-iot-vulnerability/ So bad randomness can let a remote attacker break them much more easily.
That means that even if you "random inputs" are totally predictable, the random values which come out of whitener are completely distinct, and generated RSA keys have virtually zero chances of being similar.
Earlier quoted context omitted.
>How does the disconnected audio input of any random PC or thinclient compare? That will give you RF noise, which isn't really random.
Electrical noise (including RF noise) is really random, as in it is impossible to predict exact value. It does have non-flat spectrum, meaning some values are more probable than others, but that only means you need to whiten it. (A rough analogy might be a 6-sided die labeled with 1,1,1,2,3,4 - yes, number 1 is much more likely to come out. No, this does not make it "not really random", and some trivial math can prod…