Removing Keys
There are two strategies for removing keys:
■ ■ A revocation list
■ ■ Automatic expiration of certificates
A revocation list would record all void certificates.
Devices that cannot access the list (e.g. because
they are offline) would still work with the old,
void certificates. To prevent this, automatic ex-
piration would enforce certificate renewals. The
quintessence would be the required transfer of
data to the devices you want to cover. The choice
between the two possible strategies should be
a choice between “Reliability First” or “Security
First”.
Secure Serial Number Checks
After compiling, the private key is used to
create a signature for each module (library
or application). The signature is delivered
alongside the modules, either in a separate file
or in a dedicated place in the resource section.
During testing, the checksum is created again,
skipping the signature potentially contained in
the resources. The resulting checksum is then
checked against the signature and the public key.
One Signature Might Not Be
Enough
This could be the end of the story, but the
future might bring new challenges that need
to be anticipated. Breaking with the clean
code principle that calls on developers to not
try and solve problems that do not exist yet,
security developers should always think two
steps ahead. One could ask:
1. Do we want to be protected if the private
key is stolen?
2. Do we want to give multiple developers
the ability to sign modules?
3. Should modules from business partners be
allowed in our product universe?
4. Should test and operational systems be
kept completely separate?
These are cases virtually perfect for mini-cer-
tificates. A mini-certificate essentially contains
one public key, defined sets of rights (flags),
and a signature for the public key. They are
modeled on the example of the X.509 certifi-
cate, but much leaner and easier to use with a
binary format defined by you.
How to Get a Mini-Certificate
In the first step, you create a new key pair, the
so-called “root” keys. The public key is again
integrated in the software. At the same time,
another private key pair is made, and the private
root keys are used to create a mini-certificate
for the public key of the new pair. The private
root key is then locked away, impenetrable and
protected from illicit access. Experts recom-
mend a hardcopy and two digital copies kept
at two separate places. This is indeed a viable
option, because the private root key is rarely
needed again after this point.
You then use the new private key to routinely
sign the modules you produce. The mini-cer-
tificate of the new public key is added to the
modules, and the checks compare the certifi-
cate with the public root key and the signature
of the protected data with the public key on
the mini-certificate.
More Links, Stronger Chains –
Chains of Certificates
This approach includes two tiers: The root key
pair and the key pair for active use, which
would form the recommended minimum
set. The system could just as easily include
more than two tiers, with the second private
key signing the public key of a third key pair,
eventually growing into entire cryptographic
trees. Depending on the flags you have set,
rights can be inherited, e.g. by assigning more
mini-certificates.
Additional Keys
You only need the private root key again – if
additional keys are to be created or old keys
removed. If the process uses more than two
tiers, this is even less likely, because the keys
of the second tier can be used for the same
purpose. In that case, the root key would only
ever be used again if second-tier keys are
added or removed.
Mini-certificates are also a good choice for
checking serial numbers securely: A CmDongle
is given a key pair, with the private root key
used to create a mini-certificate for the public
key. This is then delivered to the user, e.g. as
extended protected data on the CmDongle.
The testing system creates a so-called challenge
that the CmDongle signs with the private key
(or more specifically, both sides each create
a part of the challenge). A response for the
challenge and the mini-certificate are sent
back and checked with the public root key to
test the mini-certificate and make sure with
the contained key that the response matches
the challenge. If all goes well, the identity of
the CmDongle is considered proven.
This process is already frequently used to
check identities e.g. secure identities for Flexnet
or secure authentication of laser machines in
service networks.
Use Cases for Integrity
Protections
Beyond acting as a secure proof of ID, the tech-
nology is primarily used to safeguard modules
from being replaced or otherwise modified. A
license.dll could not be replaced with a fake
.dll that tricks the device into thinking that a
license is available. The system is an elegant
and easy-to-use means of encapsulating
licenses, but Wibu-Systems still recommends
automatically protecting each module with
CodeMeter Protection Suite and integrating
license checks there. How CodeMeter Pro-
tection Suite can bolster the protection for
software is outlined in “Automatic Protection
for your Software”.
11