This version comes with substantial updates to the openpgp-card-state dependency (which handles User PIN storage for OpenPGP card devices, see https://codeberg.org/openpgp-card/state).
It now supports selecting different PIN storage backends, including one to store the User PIN directly in the config file.
PIN verification error cases are now handled more defensively
NetHSM – A hardware security module with open hardware and open source code: «Unlike proprietary HSM products, NetHSM is the first HSM available as open source, which enables independent security audits, easy customization and avoids vendor lock-in. Only open source allows to verify the absence of back doors.» https://www.nitrokey.com/products/nethsm #HSM#OpenSource#OpenHardware#Security
This release shows more output for error cases, both in the log output, and with GUI notifications.
I also published an updated version 0.0.3 of https://crates.io/crates/openpgp-card-state, which contains a low-level CLI tool to help with debugging/development. This version gives more debugging output for error cases.
This release should fix build issues (the previous version didn't build on mac).
However, we're still exploring how secret storage works on non-Linux platforms. Expect a bumpy ride if you try it.
(If you do delve into debugging on mac or windows, we'd love to hear from you!)
It contains exciting UX changes: after one-time initial setup, no user interaction is required.
The User PIN for cards is persisted in platform-specific secret storage. For all users whose threat model allows persisting PINs on the host (presumably most), this removes pin entry.
Required touch confirmation on the card (if enabled) is signaled with desktop notifications.
Happy #Halloween!! 🎃 Ashika and I are both secretly big fans of #HighSchoolMusical, so we thought it’d be cute to try dressing up as Sharpay and Ryan this year!! Granted, we didn’t have all the materials, but I think we did a pretty good job 😌🎶
Started my career in cybersecurity over a dozen years ago. First assignment: fly to a client site and help deploy network HSMs. Which I had zero knowledge about.
Read the manuals on the two-hour flight. Landed as an expert 😜 Helped for two weeks, with a successful engagement and a happy client.
Today I was handed a new-to-me Yubico HSM2, and had three hours to perform and document how to stand up a new MSCA offline root with it using ECC.
Task completed 30 minutes early.
Now heading to a meeting with client to repeat the process in their environment.
Totally missed that information : a new #KSK for the root zone was generated during Root KSK Ceremony 49 last April. It's still a RSA 2048-bits key and it's keytag is 46211 if I read the log correctly
Ah! This #KSK rollover is delayed because the manufacturer of the #HSM used by IANA (and Verisign) for the KSK management will cease production of the devices used
"There is a strong likelihood we will seek to generate a new KSK on a new HSM platform once operationalized, which will cause us to abandon the recently generated KSK"
One particular focus was building CI testing infrastructure (including https://gitlab.com/hkos/virtual-piv/), to make future work on these codebases easier (and hopefully fun).
We currently sign our factory images releases with the signify tool from OpenBSD. It provides tiny signatures that are easy to verify on any distribution with signify in their repositories. This is much less important than in the past because you can verify the completed install.