KEYnote 36 English - Fall 2018 | Page 10

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.