Arch Linux

cds84

Member

Registered: 2015-03-08

Posts: 6

Shareing private keys/never-expireing keys for offline embedded utils.

I am planning on using arch to power offline arcade machines.

The machines will not have any sort of internet connection, but need to be updatable.
I will have a service that waits for a USB stick with a certain LABEL to be inserted,
When it detects it, the game software will be stopped, the disk mounted, and packages installed from that USB stick.
When complete, the game-software will be re-launched.

I need to accumplish a few things...

I need to create a signing key, and share that everyone in the software department.
I need to the Arch image to trust packages signed by that shared Key.
And i need that key to never, ever expire.

To further complicate things, the time/data on the arcade machine may be completely wrong...
Possibly in the past!

What do i need to read/do to set this up?
I need to be reasonably confident, that in 10 years, i can send an engineer out to the machines witha USB stick,
and have the updates install without issue.

Is this possible?
Or will i have to set pacman to TrustAll ?

Thanks guys.

mpan

Member

Registered: 2012-08-01

Posts: 1,208

Website

Re: Shareing private keys/never-expireing keys for offline embedded utils.

Never put private keys on the machines!!! Private keys are those for signing — devices have public keys for verification!

Generating the key should be easy (just set time to 1st of january 1970 during key creation), distributing is just about adding it to the pacman's trust db. But a maintaince-free system that has to run for 10 years, on machines that can't even keep their time right, with a rolling-release distro? Are you sure? Don't you think that a bleeding-edge environment is opposite of what you want? I would think about something more stable. Something that comes with well tested software.

However, the idea is flawed anyway. If you're expecting that the same key will work for a decade, you're blindly believing that the key will never leak. And we're talking about a key you're planning to give away to the developers! You should think more along the lines of a well protected master key (few copies in bank lockers, for examples) which is used to sign subkeys for the packagers (not just any developers) once a year or after a leak. These should be used for signing packages. Since the machines will never know about key revocation until they receive an update, even packages signed with old keys should work. I don't know, however, how well pacman deals with WoT-based trust levels — I hope some Arch devs will clarify.

---

Sometimes I seem a bit harsh — don’t get offended too easily!

cds84

Member

Registered: 2015-03-08

Posts: 6

Re: Shareing private keys/never-expireing keys for offline embedded utils.

Never put private keys on the machines!!!

Yes, i wouldnt distribute the private keys with the machines.

I would think about something more stable

The machines are actually running on the Arm architechture.
So im actually stuck with the kernel and propriatary video drivers provided by the manufacturer,

The drivers target the framebuffer, and not X11... so the actual software Im distributing is minimal.
Kernel + drivers, which i have no choice in, and from arch systemd + pacman + minimal base packages, bash etc.

The date/time issue is because the actual hardware does not have a battery backed RTC.

However, the idea is flawed anyway. If you're expecting that the same key will work for a decade, you're blindly believing that the key will never leak. And we're talking about a key you're planning to give away to the developers!

Yes... im aware that this is less than ideal.
The reason a want to keep the signing, is to prevent tampering.
The computer will be reasonaly well secured, but the USB socket will be less secured, protected by a physical lock/key.
We need ot prevent people from being able to create malicious updates, (free play), forcing the physical lock/key.
I cant lock this system down 100%... but i have to be seen to be making a reasonable effort to prevent tampering.

If i understand your advice, and the wiki's correctly, I need to...

1) Create a master key, to be kept off-line, in a safe. Key should be issued from Jan-1st-1970, and expire after 100 years.
2) Create a signing key, signed by the master key, to expire every year.
3) Create a set of developer keys, one per developer, to be signed by the signing key '2' that expire every year.
4) Setup pacman on the deployed machines to trust the master key '1'.

IF we then detect that a machine has been tampered with, then we can determine which developer key was used, and remove it from the chain of trust using the signing key.
IF it turns out that the signing key was compromised, we can remove it from the chain of trust with the master key, kept in the safe.

In these case, we issue an update with a new keys, signed by the signing key, or master key, depending on what was compromised.

IF the master key was leaked... we would have to issue a complete re-call.

The first update of the year will require a pacman key update, signed with the signing keys, as all developers keys will be new, and unknown the the deployed machines.

Am I correct ?
I am aiming to thwart the casual cracker, but avoid the nightmare situation of locking ourselves out of our own machines.
And, i understand that if an attached breaks the more secure physical lock/key, and gains acces to the hardware, There is nothing i can do but re-call.

Thanks for any help!

Chris.