When settings files are transferred as part of a program update, it may be interesting to assure that the files are not corrupted, or changed in such a way that the program is compromised. One can do this with XML Signatures.
Consider the following example:
Widgets Inc needs to create WidgetsSpecs.xml at their home office to update the WidgesFactory software at some of their many plants. In this example, WidgetsSpecs.xml is not a secret formula, but Widgets Inc wants to make sure that folks do not tamper with the settings along the way and create subversive or corrupted widgets. The following method will secure the WidgetsSpecs.xml file against tampering.
To security their specifications, Widgets Inc needs to create a private key, a self signed certificate, and then sign their WidgetsSpecs.xml files with the private key. Only the self signed certificate is passed to the application in the field and it is provided in a secure way so that it cannot be compromised. Once this is done then the software application can verify that the WidgetsSpecs.xml files are authentic.
- Widgets Inc creates a Certificate Authority, using OpenSSL, and a private key of say, 2048 bits so that it is highly secure. 2048 bits of RSA key are the normal suggested strength for computing today. This process of creating a Private Key and Self Signed Certificate is outlined here and will not be covered in detail in this tutorial. The result is this is a private file called WidgetsInc.key which is the private key and will be protected in a very secure manner by Widgets Inc. and the WidgetsCert.crt which is the self-signed certificate which is public and need not be secured.
- Once these are created, then the WIdgetsSpecs.xml file is created with some extra wrappers to contain the signature. There is an example below.
- At the Widgets Inc company, in a secure place, the WidgetsSpecs.xml file is signed using the WidgetsInc.key file. This adds a digest or hash value to the xml file which can only be verified with the correct public key from the certificate.
- When the WidgetsFactory application was built, the WidgetsCert.crt certificate was included with the application in a way so that it could not be compromised. If this crt file can be replaced by a hacker, then any signed XML file can be substituted. There are several ways to secure the crt file: (1) embed the file in the program itself rather than just placing the file on the disk where it can be changed. (2) In addition, embed a hash function of the crt file in the program so that the program can find out if the file has been tampered with.
- Each time the WidgetsFactory application starts up, it reads the WidgetsSpec.xml file and verifies the signature using the valid crt file. If the CRT file does not pass the hash checks, or the signature does not pass, the WidgetFactory application refuses to make widgets.
Cautions and Caveats
Widgets Inc could decide to spend the money on a trusted certificate from a company like Verisign for this purpose. But these certificates cost money and they expire. When creating a Self-Signed certificate there are no costs and the expiration date can be set to 5 years, if desired.
The private key is protected at Widgets Inc and is not embedded or distributed with the Widget Factory application.
These examples were taken in part from the XML Security Library site.
Using xmlsec1 to Sign and Verify the XML files.
darrell@squall-ubuntu:~/code/xmlsigntest$ xmlsec1 --sign --privkey-pem ca.key --output WidgetsSpecs-signed.xml WidgetsSpecs-Template.xml
darrell@squall-ubuntu:~/code/xmlsigntest$ xmlsec1 --verify --pubkey-cert-pem wwcdd.crt WidgetsSpecs-signed.xml
SignedInfo References (ok/all): 1/1
Manifests References (ok/all): 0/0
To examine all the files in the example, download widgetsexample.zip.
- This example was performed using Ubuntu 7.10, where xmlsec1 and the other software required is easily installed.
- The software is easily ported to Windows and the libraries have been ported to Windows by Zlatkovic.