Global Sources
EE Times-India
Stay in touch with EE Times India
 
EE Times-India > Embedded
 
 
Embedded  

Implementing embedded cryptography

Posted: 06 Sep 2011     Print Version  Bookmark and Share

Keywords:embedded cryptography  security modules  VISA  Mastercard 

The algorithms have a distinctive drawback, the consequence of providing an accurate answer to identified threats: cost, or more exactly, costs. Cost is measured in terms of execution time, memory use, power consumption, and die surface. These are not minor, insignificant issues; they are known to have forestalled or even prevented implementation of efficient security measures in devices in the past.

Proprietary algorithms and scrambling algorithms are design shortcuts, used routinely in the industry and considered sufficient. These shortcuts admittedly consume fewer resources or simplify security management.

Considered better than nothing, these solutions do not really deter attackers. Instead a professional approach to security promotes a reliable, standardised, and appropriate defence against threats that have been objectively identified.

The security industry has long understood these principles. All its history demonstrates the constant struggle between the trade-offs of lowest implementation cost versus the required level of security. An obvious example is with asymmetric cryptography (e.g., RSA, elliptic curves) where keys lengths correspond to the level of security; the longer the key is, the stronger the protection.

But yet another rule applies in this context: the longer the key is, the higher the complexity. Restated, the computation is longer and the required resources are larger. A prudent risk assessment estimates which key length is sufficient for the task and, therefore, what is the minimum level of complexity required for the implementation.

In fact, today the RSA keys used on simple devices are lengthening very slowly, while the devices' computing power increases. In the end, using too short a key weakens the implementation; using too long a key is needlessly expensive.

Embedded cryptography's evolution
Cryptographic algorithms are most commonly used in smart cards. The chip ensures security by checking cardholder credentials (typically a PIN code) and performing cryptographic operations.

Very simple in term of architecture, these cards were initially embedded with the algorithm and an 8bit core, running at few tens of megahertz. The embedded algorithm provided a few services, but absolutely could not perform any cryptographic computation. For that reason, cryptographic hardware blocks had to be added.

Initially, the cryptographic hardware blocks only performed symmetrical cryptographic operations, because the algorithms were less complex than the asymmetrical counterparts. These hardware blocks, therefore, presented a strong security limitation as they required careful management of card personalisation, the keys distribution, and the keys diversification.

Moreover, the inability to perform on-board RSA computations led to security weaknesses. Consequently, the EMV static authentication scheme was the only method used for card authentication. Because those cards were not really so "smart," that scheme was quite prone to attack from fraudulent cards.

Hackers continued to exploit the weaknesses of the RSA hardware blocks while the costs of that hardware also dropped. More secure authentication schemes based on on-board RSA computation emerged. Nevertheless, die costs still limited the length of the used keys and the core still could not perform complex computations.

Other form factors appeared in the 1990s. iButton devices enhanced security by proposing an innovative approach to keys protection and by making the platform more flexible. PCMCIA cards were also very popular for their easy acceptance in PCs, their fast data exchange rates, and larger casing.

Despite all these advances, as late as 2003 the architectures for cryptography remained the same: a slow 8bit core, typically an 8051, backed by cryptographic hardware blocks.

Other limitations remained: small RAM sizes (usually hundreds of bytes), and applications limited in scope (mostly in ROM code, especially for smart cards). The later emergence of nonvolatile memories such as EEPROMs and flash added flexibility for some applications, but did not significantly change the cryptographic conditions or methods of application.

Evolving security needs
For applications where security is a lower priority and where devices are less focused on cryptographic/security needs, a software implementation is usually the panacea.

A bootloader that checks integrity and verifies the authenticity of the embedded firmware is commonly used today to prevent most threats to consumer and industrial devices. The fundamental cryptographic needs for these less-complex secure applications are hash functions and digital signature verification, and all are solved with software implementation.

The software implementation is clearly simpler than embedded protection and does not impact the die size. It does not require a specialised hardware block that may not be used by every customer, and, finally, does not raise system costs.

 First Page Previous Page 1 • 2 • 3 • 4 Next Page Last Page



Comment on "Implementing embedded cryptography"
Comments:  
*  You can enter [0] more charecters.
*Verify code:
 
 
Webinars

Seminars

Visit Asia Webinars to learn about the latest in technology and get practical design tips.

 

Go to top             Connect on Facebook      Follow us on Twitter      Follow us on Orkut

 
Back to Top