For smart cards AES (TRK) dejan box II
 

SECURITY CERTIFICATION

ST’s ST22L128 32-bit secure MCU, for example, has received Common Criteria security certification at Evaluation Assurance Level (EAL) 5+ (Augmented), which ensures a high level of security. According to Thomasson, designers should remember they need security in all phases of communications between a card and a larger system. That means the use of public-key cryptography for the exchange of the keys during each transaction that must exchange encrypted information. “Today we have MCUs that use 1,024-bit public key cryptography to exchange keys between a card reader and contactless cards. After a system exchanges keys, it can use a technique such as the Advanced Encryption Standard (AES) to encrypt data.”


Although smart card manufacturers can implement all the software needed for an access control, banking or transportation payment system, application developers may choose to add software to answer a specific requirement. For those developers, the Java language deserves consideration.



ST’s Thomasson noted, “We designed the architecture of the ST22 MCU family to handle Java code and execute byte code efficiently.” The ST22 secure microkernel provides the first level of defense. “Then the card makers can design their own secure operating system that runs the Java Virtual Machine,” said Thomasson. “Developers of addon Java applications, called applets, have no direct access to the MCU or OS resources. Thus, we insulate the secure MCU, the OS, and the native code, and limit a card’s exposure to hacking.”


Developers of card-based systems also must address how a card communicates with its associated reader. Contactless cards present more of a challenge than do contact-based cards because a “wireless” card can operate when card holders do not know it. Parts A and B of the ISO/IEC 14443 specification for contactless cards describe an operating distance of up to 10cm. But, the ISO 15693 spec allows a working distance of up to 50cm. Unfortunately, attackers can operate contactless cards at greater ranges and can eavesdrop on card to-system communications at even longer distances.



Cards with contacts — those based on ISO/IEC 7816 specifications — present less of a problem because a user will generally insert them only in the readers associated with their use. “You must ensure cards do not give information to an inappropriate reader,” stresses Kocher. “Likewise, before a reader authenticates a card, it should not reveal anything.”





MCU VENDORS BUILD IN SECURITY

At Atmel, a manufacturer of smart card MCUs, Alex Giakoumis, director for corporate business development for smart cards and security, said, “Usually, the first level of security is that we do not talk about security.”



But Atmel’s AVR chips do implement security at different levels and include, for example, voltage detectors that let the MCU operate only between set voltage limits. Similarly, frequency detectors and temperature sensors let an MCU run only within set parameters. “We also scramble the data in several ways,” explained Giakoumis. “And we use random layouts so a hacker cannot go into an MCU and say, ‘Here is a bus and here is a CPU.’ The chips also include ‘features’ to mislead the bad guys.”



Those security capabilities appear transparent to engineers who program the AVR MCUs. “People who program in C do not have to master the architecture of a secure chip,” said Giakoumis. “But, programmers must use a secure compiler provided by an approved vendor such as IAR. The secure compiler is dedicated to all our secure and smart-card products.”



Most of these secure products have a crypto-processor that runs its own library of cryptographic algorithms, so developers do not have to write their own. Atmel provides a development emulator for its secure AVR processors and includes some development software, such as the ISO-7816 T=0 and T=1 smart-card communication protocols.



But, do not look for details about secure MCUs on the Atmel Web site. “People and companies must go through a thorough qualification process before they can buy a development kit and obtain chips,” explained Giakoumis. “Here in the US, the process can take a few weeks. In addition to gathering documents from an applicant, we send an Atmel person to talk with the company’s people and determine first hand whether they have a real application and project.”



Atmel needs to know how and where the company will secure the chips, documentation and development systems, and what sort of security system will protect them. “Our security group works with several agencies and runs its own investigations. After we receive their report we approve or reject a company’s application,” said Giakoumis.



Jean-Paul Thomasson, director, industry relations and communication for the digital secure access division at STMicroelectronics explained that ST implements the best combination of hardware and software that will minimize the

con equences of potential attacks on a card during its service. Like potential customers, MCUs also must go through security evaluations, although of a different type. “We must prove to our customers that we have implemented the appropriate security mechanisms, and we must give customers information so they can apply these mechanisms properly,” said Thomasson. “So, we use independent accredited experts and evaluation criteria described in ISO/IEC 15408, also known as the Common Criteria Methodology.” When developers apply for a final certification, they can use chip- and software developers’ evaluation and certification results as the basis for the certification of their own card. This process is called a composite evaluation/certification process


http://www.ecnasiamag.com/cmsimages/0609pg08_01.jpg