0

Is there a software signing certificates standard, officially or by popularity?

As I understand the SSL/TLS/https certificates rules are specified by the RFCs. Mixed use of servers and clients from different vendors will just interoperate without a problem. Does such kind of standard ways exist for software signing?

Or is that each software OS would use their own way of signing and need the package vendors to follow? Or ask in a specific situation, if the package signing is working well on a Linux system, would it work on other OS or platforms?

minghua
  • 165
  • 10
  • 1
    You're probably looking for [RSA](https://en.wikipedia.org/wiki/RSA_%28cryptosystem%29) – BlueWizard Dec 15 '18 at 20:08
  • 1
    What signing process you use will depend on what is going to process the signature. So, what are you needing the code signing to do? – schroeder Dec 15 '18 at 21:13
  • As far I can think of: Using different keys to sign different parts of components in the system. Distributing the signed packages through third party sites or pages. Easy revoking of signing keys or signed certificates. The system being considered would be a typical u-boot/kernel/rootfs Linux system. The signing process will be executed on build servers. The signed signatures are processed by the embedded target Linux systems. – minghua Dec 18 '18 at 04:47

2 Answers2

1

The RFC's dont technically deal with standards for code signing or TLS/SSL per se. Rather, they set the standards for x.509 certificates and PKI. Such as how you should construct a x.509 certificate using asn1 (RFC 5280) and then how it should be encoded to create a certificate.

The standards for TLS/SSL and code signing certificates which are issued by Certificate Authorities (CA's) such as GlobalSign, Digicert, Sectigo, etc are subject to the CA/B forum Baseline requirements. Code signing certificates for the Windows ecosystem fall into this category.

However, if you are signing code on Linux you might be using a PGP certificate and key to apply the signature. In this scenario, you would be using the PGP web of trust instead of CA's.

As I understand the SSL/TLS/https certificates rules are specified by the RFCs. Mixed use of servers and clients from different vendors will just interoperate without a problem. Does such kind of standard ways exist for software signing?

Code signing, document signing, TLS/SSL, S/MIME, are all examples of different types of x.509 certificates being used for different purposes. The x.509 certificate and key files are essentially cross platform because they all adhere to the same RFC's on how to construct and use the files. You can use the x.509 certificate to apply a digital signature to a file. How to construct digital signatures is (I think) in RFC 2315.

Or is that each software OS would use their own way of signing and need the package vendors to follow? Or ask in a specific situation, if the package signing is working well on a Linux system, would it work on other OS or platforms?

How each OS handles the signatures varies. Windows requires code to be signed using a code signing certificate issued via a CA. If the code is executing at the kernal level, then you have to buy a EV Code Signing certificate and submit the code to Microsoft for review. Linux however does not require code to be signed by a code signing certificate. Instead, Linux uses the PGP web of trust to verify PGP signatures in the repository. Packages ported from Linux to Windows will not be trusted on Windows because Windows doesnt use the PGP web of trust. Same in reverse, Windows applications ported to Linux will not be trusted unless you sign it with a PGP key and you import the PGP certificate into the clients PGP keystore. Apple also has its own requirements and you can find their documentation here.

Community
  • 1
Rex Linder
  • 141
  • 4
  • 1
    In addition to Windows and Apple, Android and Java use X.509-ish certs -- although now that Java has given up its long struggle for the 'deploy over Internet' model it has less need (Oracle JREs do still require signing of cryptoprovider jars). So does PDF, which contains postscript and thus could count as signed code depending on your definition. – dave_thompson_085 Oct 14 '20 at 00:34
  • For anyone in the future interested in code signing on android, [this link](https://developer.android.com/studio/publish/app-signing) should provide you the info you need. They are still x509 certs, just packaged in a Java Keystore format. – Rex Linder Dec 11 '20 at 22:45
0

Preliminary I can see there is no such a standard for softwares from different companies. Standards from each of the software vendors could exist, but not in publicly available documentations. Probably you need to sign-up to a code-signing package from a vendor to exercise the process to find out more. Even though that probably will not be straight and simple to find out the signing details because most of the packages poorly document the internals than just showing you the steps.

The signing key most likely will be RSA, as @BlueWizard pointed out in the comment.

The signed certificate, should contain the subject public key with other directives or meta-information. The subject public key should be verified by the signer public key.

Let's use a subject as an example who produces software. A sequence of steps could be:

  • [1] The subject submits the subject public key to the authority signer.
  • [2] The authority signer put the subject public key with some meta-information together, and encrypt it with the signer private key. This produces a certificate. The certificate is returned to the subject.
  • [3] The subject puts the hash of a to-be-signed software image with the certificate into an unsigned or to-be-signed package.
  • [4] The subject encrypts the unsigned package with its own private key.
  • [5] The subject publishes the signed package and its signing public key.
  • [6] The receiver decrypts the package with the package signing public key. Then decrypts the certificate with the authority public key. If the decrypted certificate message contains the obviously verifiable meta information the validation is successful. The meta-information put in by [2] and verified here probably will contain the name of the signing authority and the name of the subject, when the certificate was signed, and when its validity shall expire, what it should be used for, etc.

An exception to the above is that, if the package signing key used at [4] is different from the certified key, the subject needs to encrypt the signing public key using the certified private key. This creates an intermediate certificate.

The meta-information involved in [2] and [6] should be specified by the signing and validation standard.

minghua
  • 165
  • 10
  • I post this as a partial answer, in wishing that experts will come up with a better answer or provide feedbacks to make this answer more complete. Questions: Is this process secure enough? How can it be improved? – minghua Jan 22 '19 at 17:49
  • Signing is not encryption, not even for RSA; see (my) https://security.stackexchange.com/q/159282/ . And the certificate(s) is(are) never included in the data subjected to the actual signing algorithm; instead it is (they are) placed _alongside_ the basic signature, using a structure such as PKCS7/CMS (or for that matter, PGP). – dave_thompson_085 Oct 14 '20 at 00:37