Tuesday, February 18, 2020

Enroll Using Device Certificates Using CMP with 3GPP/LTE


About 3GPP/LTE

The 3rd Generation Partnership Project, 3GPP, has produced a technical specification for an entity authentication framework, which was developed in the context of the Network Domain Security work item.

In practice, the main purpose of using CMP 3GPP is to allow a device to automatically provision itself with a device certificate without the vendor being required to expose their full PKI to the manufacturer. A typical use case is an IOT device vendor, whose devices are manufactured by a second party, and the vendor requires the devices to be enrolled to their PKI. The vendor may wish to prohibit the manufacturer from producing their own pirated devices that connect to the vendor's PKI, or is simply unwilling to expose their PKI directly to the manufacturer in order to enroll the devices on site.

 To solve this, the following workflow is usually followed:


  1. The factory site is provisioned with a Vendor CA, separate from the main PKI intended to be used. The Vendor CA certificate is signed by the vendor's PKI. 
  2. The vendor prepares a series of unique identifiers (i.e serial numbers) for each device to be produced. This ensures that only the authorized set of devices will be able to enroll against the vendor's PKI. 
  3. As each device is manufactured it produces its own key pair. The public key is signed by the Vendor CA, and the device is initially provisioned with a Vendor Certificate (which includes the serial number). 
  4. As each device comes online it enrolls to the vendor's PKI over CMP with 3GPP, using the Vendor Certificate to authenticate itself. 
  5. The device then receives its device certificate from the vendor's PKI. 

Generalized Workflow

This section describes the general CMP 3GPP workflow, purely for overview purposes. The EJBCA specific workflow is slightly modified, see the next section. Next figure shows the general deployment architecture for certificate enrollment of a device at an operator PKI:


The device is either pre-provisioned with a public-private key pair by the vendor or produces its own, and has the vendor-signed certificate of its public key pre-installed.

On initial contact to the operator network, the device establishes a communication channel to the RA/CA of the vendor. Using a CMPv2, a request for a certificate is sent to the RA/CA. The network authenticates the messages from the device based on the vendor-signed certificate of the device and the vendor root certificate pre- installed in the network. The device checks the integrity protection on the messages from the RA/CA based on the operator root certificate provisioned in the device. In a response message, the device receives the operator-signed certificate. During the execution of the CMPv2 protocol, the device has to provide a successful proof of possession of the private key associated to the public key in order to be certified.

The operator root certificate may be provisioned in the device prior to or during the CMPv2 protocol run. The protection of the operator root certificate during provisioning may be decided by operator security policy. If an operator root certificate provisioned prior to the CMPv2 protocol run is available, the device shall use it. Otherwise, the device shall use the operator root certificate provisioned during the CMPv2 run. If no operator root certificate is provisioned at all, then the device shall abort the procedure.

If the operator wants to renew the device certificate, the same procedure will be executed with the old operator-signed device certificate taking the place of the vendor-signed certificate of the initial enrollment.

The figure below describes the general message flow in both cases:

  1. The device discovers the RA/CA address.
  2. The device generates the private/public key pair to be enrolled in the operator CA, if this is not pre-provisioned.
  3. The device generates the Initialization Request (IR). The CertReqMsg inside the request specifies the requested certificate. If the suggested identity is known to the device, it includes this in the subject field. To provide proof of possession, the device generates the signature for the POPOSigningKey field of the CertReqMsg using the private key related to the public key to be certified by the RA/CA. The device signs the request using the vendor provided public key, and includes the digital signature in the PKIMessage. Its own vendor signed certificate and any intermediate certificates are included in the extraCerts field of the PKIMessage carrying the initialization request.
  4. The device sends the signed initialization request message to the RA/CA.
  5. The RA/CA verifies the digital signature on the initialization request message against the vendor root certificate using the certificate(s) sent by the device. The RA/CA also verifies the proof of the possession of the private key for the requested certificate.
  6. The RA/CA generates the certificate for the device. If the suggested identity of the device is not included in the initialization request message, the RA/CA determines the suggested identity, based on the vendor provided identity contained in the device certificate. The RA/CA may also replace a suggested identity sent by the device with another identity based on local information.
  7. The RA/CA generates an Initialization Response (IP) which includes the issued certificate. The RA/CA signs the response with the RA/CA private key (or the private key for signing CMP messages, if separate), and includes the signature, the RA/CA certificate(s) and the operator root certificate in the PKIMessage. The appropriate certificate chains for authenticating the RA/CA certificate(s) are included in the PKIMessage.
  8. The RA/CA sends the signed initialization response to the device.
  9. If the operator root certificate is not pre-provisioned to the device, the device extracts the operator root certificate from the PKIMessage. The device authenticates the PKIMessage using the RA/CA certificate and installs the device certificate on success.
  10. The device creates and signs the CertificateConfirm (certconf) message.
  11. The device sends the PKIMessage that includes the signed CertificateConfirm to the RA/CA.
  12. The RA/CA authenticates the PKI Message that includes the CertificateConfirm.
  13. The RA/CA creates and signs a Confirmation message (pkiconf).
  14. The RA/CA sends the signed PKIMessage including the pkiconf message to the device.
  15. The device authenticates the pkiconf message

EJBCA Specific Workflow

To use EJBCA with 3GPP, the setup above should be slightly adjusted:

Direct CA - Device Communication

In the case of direct contact between EJBCA and the device, EJBCA operates in client mode. Each device has a corresponding end entity in EJBCA. The initial enrollment request/certification request is send by the device to EJBCA as a CMP request signed by the key provided to the device by the vendor. The vendor issued certificate is attached to the request in the extraCerts field. EJBCA will authenticate the request by checking that the certificate in extraCerts was issued by the vendor CA (an external CA in EJBCA). If the authentication succeeds, EJBCA will issue a certificate for the device and includes it in the CMP response message.

For future communication, when the device needs to update its certificate, the old EJBCA obtained certificate is used to authenticate the update or key renewal request. This is typically done by the device signing the update request with its private key and attaching its certificate (the one to be renewed) in the extraCerts field in the CMP message.

CA - Device Communication Through a Bespoke RA

In case of indirect communication between EJBCA and the device, EJBCA operates in RA mode. The device communicates with the CA through a third device/organization that acts as an RA. The RA has a corresponding end entity in EJBCA with an issued certificate. This certificate is transported to the RA manually. The RA is also registered in EJBCA as an administrator and is given the necessary privileges to process CMP requests on behalf of the device.

Both initialization/certification requests and certificate update requests regarding the devices, are expected to be signed by the RA. Any changes or updates of the RA certificate are expected to be performed directly in EJBCA and transported to the RA manually.

Cheers,
Mike Agrenius Kushner
Product Owner, EJBCA

Wednesday, October 9, 2019

PGP Signing with SignServer


This blog post covers PGP signing support implemented in recent versions of SignServer

In a previous blog post, we addressed Code Signing of Windows binaries (Authenticode) and gave some background on why Code Signing is important for secure software distribution.

We are now pleased to introduce code signing with PGP, commonly used for Open Source software projects and packaging of software for Linux environments in general.

OpenPGP Signing was first implemented in SignServer Enterprise 5.1 and will be available in SignServer Community 5.2, already available for download as a beta release.

SignServer Installation

To test the PGP support, download and install SignServer Enterprise 5.1 or SignServer Community 5.2.0.Beta1 or later.

For installation instructions, refer to SignServer Installation.

Setting up an OpenPGP Signer

When SignServer is up and running, access the SignServer Administration Web to start setting up the workers.

The Administration Web is available in SignServer Community as if 5.2.0.Beta1.

Step 1: Set up Crypto Worker

If you don’t already have a crypto worker configured, then set one up using, for example, the sample keystore:
  1. Select the AdminWeb Workers tab, and click Add.
  2. Click From Template, select keystore-crypto.properties in the list, and click Next.
  3. In the configuration text view, change the value for WORKERGENID1.KEYSTOREPATH so that the path corresponds to your SignServer installation, for example: WORKERGENID1.KEYSTOREPATH=/home/username/signserver/res/test/dss10/dss10_keystore.p12. 
  4. Click Apply.
Remember the name of the crypto worker (for example, CryptoTokenP12) as you will need it in the next step when setting up the OpenPGP Signer.

Step 2: Set up OpenPGP Signer

To set up the new OpenPGP signer, do the following:
  1.  Select the SignServer AdminWeb Workers tab, and click Add to add a new worker.
  2. Choose the method From Template.
  3. Select openpgpsigner.properties in the Load from Template list and click Next.
  4. Change the sample configuration properties as needed, for example:
    • Update the CRYPTOTOKEN property with the name of your crypto worker (for example, CryptoTokenP12).
    • Update DEFAULTKEY to an existing key (or do this in a later step).
  1. Click Apply to load the configuration and list the worker in the All Workers list.
  2. Select the added worker in the list to open the Worker page.
  3. Check if the Worker status is Offline and if there are any errors listed. The "No key available for purpose" message means that the DEFAULTKEY property does not point to an existing key in the crypto token. In that case, either update the DEFAULTKEY property to point to an existing key or do the following to generate a new key to use with this signer:
    • Click Renew key and specify the following:
      • Set a Key Algorithm, for example "RSA".
      • Set a Key Specification, for example the key length "2048" (for RSA).
      • Update the New Key Alias to the name of DEFAULTKEY property (typically change to the same value as the Old Key Alias).
    • Click Generate.
    • Select the worker in the list and confirm that the Worker status is Active and without errors listed. If not, confirm that the DEFAULTKEY property is correct and check in the Crypto Token tab of the crypto worker that a key with the specified name exists.

Step 3: Add User ID to Public Key

Follow the steps below to add User ID / Certification for the OpenPGP public key using the Generate CSR option.
  1. Select the AdminWeb Workers tab.
  2. Select the OpenPGP worker and click Generate CSR.
  3. Specify a Signature Algorithm, for example "SHA256withRSA"
  4. Specify DN as the wanted User Id, for example "Markus (Code Signing) <markus@primekey.se>".
  5. Click Generate, and then click Download.
  6. Open the downloaded file using any text editor and copy its content.
  7. Select the worker and click the Configuration tab.
  8. For the PGPPUBLICKEY property, click Edit.
  9. Paste the public key content in the Value field, and click Submit.
  10. Click Status Summary and confirm that fields like PGP Key ID and PGP Public key are listed. Also, note that the User ID is listed. 

Step 4: Sign

The following example shows how to sign using the SignServer Public Web. You can test signing using any of the SignServer client interfaces.
  1. Click Client Web.
  2. Under File Upload, specify the Worker name used, for example, OpenPGPSigner.
  3. Select the file to create a detached signature for, for example, release.zip.
  4. Click Submit and store the resulting signature file, for example, release.zip.asc.

Step 5: Verify Signature

The following example shows how to verify the signature using the OpenPGP tool GnuPG. It should be possible to use any OpenPGP tool to verify the signature.

Run the following to verify the signature using GnuPG:
$ gpg --verify release.zip.asc release.zip

If needed, first import the public key to GnuPG before verifying the signature in the third step:
  1. Store the public key (i.e. from PGPPUBLICKEY property) as signer001-pub.asc.
  2. Import the key to GnuPG:
    $ gpg --import signer001-pub.asc

More Information

See also the OpenPGP Signer documentation and if you have any questions or comments don't hesitate to use our discussion forums.

Cheers,
the PrimeKey SignServer Team