Hi,
I am finalizing my work on my ADS driver module and am currently implementing the signing with a real code-signing key. So for that I got a pair of code-signing keys on yubikeys from ssl.com ... now when it comes to signing the modules the "module-signer" that ignition provides is hard coded to validate only SHA256withRSA.
I could patch my version of the module-signer (and if wanted could provide a PR for the upstream version) to also support the secp384r1 setup that I have. But that only makes sense, if Ignition knows how to handle these.
So before starting to work on patching the module-signer, I wanted to double-check if Igntion would support the other type of signatures?
Chris
No
It's too late it sounds like, but there's very little reason to get a real code signing certificate, or even a real certificate at all. The module signing idea is really half-baked / half-implemented.
Concur. I stopped a while ago. I made a code signing cert as an intermediate under my long-standing private CA. Tucked into a Yubikey and a Nitrokey (home/work).
Oh ... ok ... Well I thought: Nobody trusts a self-signed certificate, so I guess I need one.
So you think, instead of investing another 500€ for two new keys, just stay on self-signed ones? Is that generally accepted with Ignition users? Guess I can use my tokens for signing modules for other platforms, that I'm going to be targetting.
Even if we improve the module signing situation some day, my vision for it is an area of the Ignition Gateway where you can manage the CAs you trust to sign modules that are installed on that Gateway.
IA doesn't want to be involved in blessing modules, so you'll never get signatures from us. I don't see why you'd want to get a commercial CA involved either. This seems like something you want to manage internally. So - either adding internal CA for your own internal modules, or carefully and intentionally adding the CA for trusted third parties whose modules you want to install.
1 Like
Well ... a formally issued code-signing certificate does come with some advantages. You can trust that only someone with the hardware token can have signed a module (Since 2023 code signing certificates are not distributable as files, they need to be bound to hardware and be unextractable). So it adds quite a layer of security ... right now my self-signed certificate (if I'm stupid) someone could snitch and start selling "official ToddySoft GbmH" modules.
The validation process was also quite painful ... so it would be hard to fake the Identity for one of these certificates ... with self signed, I could create one stating: "I'm Kevin Herron" and there would not really be a way for users to validated that.
But ... with the quantum computing aera coming closer ... RSA certificates will be rendered useless as soon as we're there. EC currently sill seem quantum-safe.
No, anyone can make their own code signing certificates if a private CA is trusted. Which Ignition allows.
I, for one, have no desire to tie myself into the publicly trusted certificate ecosystem, as classic a "rent seeking" bureaucracy as ever existed, unless Let's Encrypt launches a free, automated source for them.
Yeah ... but the certificate authorities that are generally trusted (so you don't have to explicitly trust them) do have to fulfill a lot of rules to be allowed to keep their status. The Code Signing Baseline Requirements (CSBRs) for example: The specific provision is in Section 6.2.7 ("Subscriber Private Key Protection"), which mandates that the private key for a code-signing certificate must be generated and stored in a hardware crypto module meeting at least FIPS 140-2 Level 2, Common Criteria EAL 4+, or equivalent — and that the key must be non-exportable from that hardware.
That's in effect since first of June 2023.
I did have Kyptography as one of my major blocks at the university. There we were working on post-quantum crpyto and eliptic curve algorithms ... the root of trust is always the hardest problem.
So yes: Anyone can create a code-signing certificate (I did for my beta-tests). But you must trust that the issuer is who he claims to be and you can't really guarantee things.
But ... considering that we're in a domain where most devices give full access to everything without even asking for credentials ... would be silly to go nuts with trust when installing modules 
This leads to
In other words, the global convenience of publicly trusted roots is a trade-off for users.
The most secure certificate is one manually validated by an end user, and manually pinned.
This really [expletive]es off public roots, such that they take active steps to make it hard for users to do. Protecting their revenue stream, of course, at users' expense.
(Criticism of auto-pinning schemes is entirely valid, though.)
The cryptography in Secure Shell is entirely based on pinning, and is as secure as end users desire. You just have to manually establish the pin on first connection.