The security characteristics of a transactional system must be considered from two angles. First, data must be secured on the device itself. If ID information and keying material is poorly protected, the system itself is insecure from the start. Second, data must be secured during the transaction and after it is completed. For device protection, especially in constrained devices such as cell phones and PDAs, the preferable security architecture has a cryptographic engine at its core, supported by a common set of application programming interfaces suited to a wide range of requirements. The versatility of such APIs allows developers to embed interoperable security protocols quickly and easily. Together, the engine and the APIs make up what's known as the cryptographic service provider, or CSP.
Some developers are keen on the idea of using a completely software-based CSP, but in reality there is a significant performance advantage to including both hardware and software elements. The use of hardware strengthens security overall, via:
- True hardware-based random-number generation. Nearly all modern cryptographic security is based on randomness. This depends on a supply of truly random bits that can be created only through specialized hardware. (Software is out of the question, as it can only condition a string of data through programmed methods, meaning the result is in some way predictable.)
- Hardware acceleration of cryptographic algorithms—for symmetric (DES, 3-DES, AES), asymmetric (ECC, Diffie-Hellman, RSA), and supporting algorithms (SHA-1, SHA-2). Acceleration provides the capability to operate stronger security algorithms with less delay and less power consumption. This encourages system and protocol designers to make use of strong security. Here, overbuilding for the future is nearly always worth the effort and investment: as mobile transactions become more common, security will be increasingly critical. Devices that have a small bit of additional capability to provide efficient, secure operation will have a competitive advantage.
- A secure bootloader for device-code integrity including code signing. This provides a 'trusted' core for the device from which other software operations can be validated.
- A secure execution mode enabling secure key storage and runtime authentication. Because protecting the keys is the root of a secure system, providing secure key storage is critical to trusting devices. Further, while the use of keys allows an attacker the opportunity to collect information on them, if the keys are used only in a secured hardware block, this point of attack can be made inaccessible.
For mobile devices, both the hardware and software aspects of the CSP must have small footprints. The CSP can't monopolize the resources of the device and must leave room for other programming elements; after all, the device exists to provide services.
On the software side, code size can be minimized through design. A CSP should:
- Allow developers to compile out unused algorithms that minimize the code base, which has the benefit of providing only the operations that are necessary.
- Be flexible—configurable in ways that support faster processing, lower power consumption and more efficient bandwidth utilization.
- Conform to reigning standards. This often doesn't yield a smaller footprint, but does enable the device to operate in the physical world.
