S E C U R I T Y
Acquiring Trust with Mini-Certificates
“My installation package includes one application and many libraries. I need to prevent hackers from replacing individual
libraries, especially the license.dll. Using checksums might be an option, but I would have to recompile and distribute the entire
package again.” This would be a typical problem faced by software developers everywhere. Their answer to this challenge, or
to similar problems like a secure check of serial numbers, would normally be mini-certificates: a powerful tool for many use
cases. What can they do?
Simple Checksums
A checksum is the end result of a function that
turns data strings of any length into a single
number. If the data is changed, the checksum
changes as well. Popular examples include CRC
and Modulo operations, which are frequently
used to prevent or reduce mistakes in data entry
or transmission. Credit card or IBAN numbers
come with checksums to allow the systems to
notice incorrect entries before the data is ever
sent to the bank, retailer, or service provider.
Cryptographic Checksums
Simple checksums are not viable defenses
against malicious acts. For effective fraud
prevention, cryptographic checksums are
needed that change substantially in response
to even a tiny change to the underlying data.
It would be impossible to manipulate the
data in such a way that the checksum itself
remains unchanged, e.g. by adding blank
spaces until the data corresponds to the same
checksum again. One popular current choice for
cryptographic checksums is SHA256; the MD5
10
approach that was used frequently in the past
is now considered insecure.
Cryptographic checksums are not without
their own limits: To test a checksum, one
needs the same information from when it
was created originally, i.e. the function itself
and an optional salt value as the shared
secret. This information needs to be kept in
the software whose checksums are tested. If
even a single attacker manages to get at this
data, the entire system is compromised, as
valid checksums could be created that could
never be identified apart from the originals.
This conceptual restriction has led to some
labyrinthine constructs, with checksums for
different libraries kept in other libraries again
or in the core application – unwittingly creat-
ing the problem of updating entire software
packages mentioned already.
Asymmetric Cryptography
The solution can come from asymmetric cryp-
tography, in the form of key pairs with one
private key that is kept secret and one public
key that is out in the open. The private key can
be used only by their legitimate owner to sign
something; the public key can then be used
by anybody to check the signature. Having the
public key does not, however, enable anyone
to create a valid signature.
Asymmetric cryptography is typically a slow
and laborious process that requires data of a
certain size, which is why it is often combined
with cryptographic checksums. First, a check-
sum of the data is created and signed with
the private key. For later testing, the same
checksum is created again and tested against
the public key and signature. ECDSA and RSA
are established processes in this area.
The Basic Tools
The basic toolkit for signing our libraries and
applications is described here. As the first step
in the development process, the public key is
included in the software.