Page 39

EETE JULAUG 2014

The sequence below outlines the actions needed to implement an integrity protection system. The boot loader verifies the integrity of the operating system and loads it after validation. The operating system only starts once the boot loader has been validated to be trustworthy through a reverse check. The operating system verifies the integrity of the application and loads it only if it has been validated. The application only starts if the operating system has been validated to be trustworthy through a reverse check. The application verifies the integrity of the configuration data and only uses it if successfully validated. Should the configuration data also contain executable code, a verification of the application level of trust is also possible. Additionally, the unprotected original software has to be signed and encrypted in accordance with the following procedure: Hash values of the original software have been calculated. The hash value has been signed with the private key of the vendor. The original software has been encrypted using a key that is generated from a seed value within the original software, a secret key of the vendor, and some other parameters that the publisher selects. The public portion of the signature certificate has been attached to the encrypted software. The first part of the integrity check is the forward check, (i.e., the verification of the software to be loaded or the corresponding data) and consists of the following steps, which are executed while the application is being loaded: The encrypted software is decrypted if a valid license is present.. The certificate attached to the credentials or the certificate chain is verified against the public root key. The hash value of the decrypted original software is calculated. The signature of the hash is verified using the public key. Furthermore, extra measures can be implemented to increase the security to a higher level, such as advanced handling of certificates for the authorized use of a specific device. It is also possible to implement checks against a preset expiration date of the certificate, or the existence of a certificate revocation list. Such verifications can be executed periodically at runtime in the system memory (watchdog). The backward check then verifies whether the boot process was executed correctly by the operating system. Unless this step is present, the integrity check of the operating system by the application is difficult to carry out because the subsequent step has only limited access to the previous step. To compensate for the missed access, a state machine in a trustworthy hardware is needed. Such configuration is found in the Trusted Computing Group. By using the so-called Trusted Platform Modules, it is possible to save correct states in registers. These registers include, for example, measurements of the boot loader, which will be considered later by the operating system to verify the integrity of the previous step. At the end of the day, a safe first step is essential, since all subsequent checks depend upon its accuracy and requires that no attacker is ever able to decipher the code, or extract secret keys. One solution is called “System on Chip” (SOC), in which these codes and keys are stored permanently on the chip, safe from any reading or manipulation attempted from the outside. This compact pre-boot loader simply ensures the integrity of the actual boot loader. To prevent attacks from the outside, it is developed only once and cannot be updated on the system. Private keys are then used for signing the program codes and parameters. These are saved in a secure hardware device. The certificates are saved as files and contain the public key, validity restrictions (for example, an expiration date or a binding to a specific device), the purpose (for example, to sign the boot loader, the application, the configuration files, or to create other certificates), and the certificate of the key that was used to create this certificate chain. The root certificate is stored securely and only used when new certificates must be created. The root certificate must not be compromised under any circumstances whatsoever. The integrity of embedded systems can be ensured using cryptographic methods in a clearly defined process and a secure hardware device for key storage and state machine. Secure implementation of symmetric and asymmetric encryption methods (AES, RSA, and ECC) as well as hash functions (SHA-256), functions for signature validation (ECDSA), and a random number generator allow the implementation of the explained mechanisms. One commercial solution offering encryption and signature of the program code, storage of the shared secrets for decryption, storage of the private keys on the vendor’s site, signature and hash verification during loading and runtime operations, and support of both traditional computer platforms, as well as embedded systems like VxWorks, PLCs like CODESYS, and OPC UA authentication, communication encryption and certificate deployment, is CodeMeter® from Wibu-Systems (www. wibu.com). CodeMeter’s technology, which received the CODiE Award 2014 for Best Content Rights and Delivery Solution, goes beyond product and know-how protection: it also improves logistics and business processes. A fully integrated lean and flexible license management system responds to needs such as license scalability, enablement of new business models, and upselling features. Time or volume-limited licenses are available for installation, maintenance, and repair services. This conditional option generates interesting new business opportunities for mechanical engineers, as it allows product designs to be restricted to a defined production run or batch size. The machine itself becomes a first line of defense against illicit products like expensive designer fashions being produced in clandestine ‘third shifts’ and placed into the black market trade. www.electronics-eetimes.com Electronic Engineering Times Europe July/August 2014 39


EETE JULAUG 2014
To see the actual publication please follow the link above