To prove authenticity and integrity the Software Packages can be signed.

Initially the Software Package should be signed by the author (e.g., the manufacturer signs a firmware for its devices when it is created). This signature proves that it is really from that author (authenticity) and that is not altered on the way to the client (integrity) (see use case 8.2.2.20).

The verification of these signatures can be done by the Update Client or by the device if the whole update package is deployed.

Typically, a PKI with a certificate hierarchy is used. In this case, the entire certificate chain shall be stored in the signature. Consequently, only the root certificate is required for verification.

Additional signatures can be added by machine builders or plant operators to approve a Software Package for use in a specific plant. With this in place the Update Client and OPC UA servers can be configured to only allow updates of Software Packages with an approval signature of a specific certificate hierarchy (see use case 8.2.2.21).

To create a signed Software Package, it is stored as a standard ASiC-E (Associated Signature Container) container and signed with a CAdES (CMS Advanced Electronic Signatures) signature.

Note: These *AdES signatures are commonly used for advanced digital signatures in engineering environments. Examples are FDI, Profinet or OPC UA FX descriptors. To be easier usable on constrained devices the Software Packages use the binary CAdES persistence instead of the XML based XAdES. ASiC-E is a minimalistic ZIP container from the same family of standards.

With ASiC-E the folder structure of the ZIP file does not change. ASiC-E adds one additional folder “META-INF” with the signature information and a mimetype file in the root folder. These signatures also remain intact if individual files are removed or if the folders are unzipped.

Depending on the industry and environment where the devices are used there are different requirements to the level of security of the signatures. Therefore, the CAdES signatures support different levels which all can be used for the Software Packages. The more advanced options extend the basic option so that all packages remain compatible and usable with any update client.

For the verification of the signature, all certificates up to the root certificate are required. To ensure ease of handling, the entire certificate chain should therefore be incorporated within the CAdES signature.

All security relevant details are described in the publicly available ETSI standards (see ASiC-E, CAdES).

Note: If the complete Software Package is transferred to the device the verification also shall be done on the device. For this case certificates are distributed and updated on all device in the plant. Solutions for certificate distribution are covered in detail in OPC 10000-12 and OPC 10000-21.

Note: To create and maintain keys and certificates for the signatures, a PKI (public key infrastructure) should be used. Since this has no impact on the singing and verification described in this document, it is out of scope of this specification.