Communities

Writing
Writing
Codidact Meta
Codidact Meta
The Great Outdoors
The Great Outdoors
Photography & Video
Photography & Video
Scientific Speculation
Scientific Speculation
Cooking
Cooking
Electrical Engineering
Electrical Engineering
Judaism
Judaism
Languages & Linguistics
Languages & Linguistics
Software Development
Software Development
Mathematics
Mathematics
Christianity
Christianity
Code Golf
Code Golf
Music
Music
Physics
Physics
Linux Systems
Linux Systems
Power Users
Power Users
Tabletop RPGs
Tabletop RPGs
Community Proposals
Community Proposals
tag:snake search within a tag
answers:0 unanswered questions
user:xxxx search by author id
score:0.5 posts with 0.5+ score
"snake oil" exact phrase
votes:4 posts with 4+ votes
created:<1w created < 1 week ago
post_type:xxxx type of post
Search help
Notifications
Mark all as read See all your notifications »
Q&A

Welcome to Software Development on Codidact!

Will you help us build our independent community of developers helping developers? We're small and trying to grow. We welcome questions about all aspects of software development, from design to code to QA and more. Got questions? Got answers? Got code you'd like someone to review? Please join us.

Comments on How to properly manage PGP signing key storage, access, and usage for dev and automation?

Post

How to properly manage PGP signing key storage, access, and usage for dev and automation?

+1
−0

I work for an IoT company. We recently got secure boot to work for a customer-visible product. For secure boot to work, the images we generate must be signed. Obviously, we want customer-visible system releases to be signed. However, we need to make sure our signing keys are stored, accessed, and used properly.

At a high level, given our current infrastructure (Docker, Jenkins, etc), we seem to have 3 options:

  1. Put the keys in the Docker images used to generate the customer releases;
  2. Make it so that only Jenkins has an automated process to access keys and sign the images;
  3. Build a separate internal service where images to be signed get submitted by automation and/or users.

The problem with #1 is that the signing keys would be everywhere and every dev/QA user using the Docker images would have access to the keys, by definition. We'd like to avoid this.

The problem with #2 is that it looks very similar to #1, but with additional steps. In addition, anyone with sys-admin access to the server(s) would also have access to those keys. While this is a smaller subset, all the knowledge of how/where to access keys would also be visible in automated scripts, which are visible to everyone. We'd also like to avoid this.

The main issue with #3 is that we're concerned that it might become a bottleneck. (The images to be signed are hundreds of MBs, so transfer speeds from homes over VPN become an issue quickly, among other things.) At least in my opinion, this one seems to be the most promising regarding secure storage, controlled access, and so on.

Proper key storage and controlled access/usage is also a concern and, personally, I'm leaning towards option #3 for the following reasons:

  1. Keys stored in a single internal server;
  2. Keys accessed indirectly in controlled manner;
  3. Server access is limited to a very small number of people;

Regarding actual key storage, I had considered using the Gnome Keyring, but that seems to require an X session, and having graphical environments in a server is something we don't intend to do.

Given the options, infrastructure, and constraints I mentioned:

  1. What are some good options could we consider to manage image signing when we want secure boot enabled?
  2. What are good key management approaches we could realistically consider/use?

For #2, I'm thinking about the possibility of generating "ephemeral" keys signed by the root/master key. This seems like it could help alleviate the image transfer issue, because you'd be transferring short-lived keys and signing locally, not transferring the images - but this also seems like a potential security hole and extra work for the actual controlled access.

I'd appreciate good recommendations so that we can properly/securely manage our keys while allowing devs and automation "Easy"(tm) ways to sign generated images when needed.

History
Why does this post require moderator attention?
You might want to add some details to your flag.
Why should this post be closed?

2 comment threads

Scope and universality (2 comments)
PGP or GPG? (4 comments)
Scope and universality
President James K. Polk‭ wrote over 2 years ago · edited over 2 years ago

This can be a tricky problem that is much harder than it appears. First off, what is the scope of your signing keys? How many are there? Is there a different one for each of your devices, or is there a single one for all? Can one customer's signed code run on another's IoT device? What is the value of the protection being offered, or almost equivalently, what is the value to a malicious actor to subvert your process? Could they steal your customer's IP, cause the customer to shutdown all their systems by falsifying sensor readings, etc?

ghost-in-the-zsh‭ wrote over 2 years ago

> First off, what is the scope of your signing keys?

Not sure what you mean there

> How many are there?

We expect to have 2 keys, but I don't know what the future holds.

> Is there a different one for each of your devices, or is there a single one for all?

We don't put keys on devices. The intent is to use the keys to sign the binaries that will run in the devices.

I've ignored your other questions because they don't seem relevant to my question and I'd like to avoid going down rabbit-holes with red-herrings.