Page 149 - DCAP305_PRINCIPLES_OF_SOFTWARE_ENGINEERING

Unit 6: Functional Design

Notes

Java Card Security Testing

n an effort to enhance payment cards with new functionality—such as the ability to
provide secure cardholder identification or remember personal references—many credit-
Icard companies are turning to multi-application smart cards. These cards use resident
software applications to process and store thousands of times more information than
traditional magnetic-stripe cards.
Security and fraud issues are critical concerns for the financial institutions and merchants
spearheading smart-card adoption. By developing and deploying smart-card technology,
credit-card companies provide important new tools in the effort to lower fraud and abuse. For
instance, smart cards typically use a sophisticated crypto system to authenticate transactions
and verify the identities of the cardholder and issuing bank. However, protecting against
fraud and maintaining security and privacy are both very complex problems because of the
rapidly evolving nature of smart-card technology.
The security community has been involved in security risk analysis and mitigation for Open
Platform (now known as Global Platform, or GP) and Java Card since early 1997. Because
product security is an essential aspect of credit-card companies’ brand protection regimen,
companies like Visa and MasterCard spend plenty of time and effort on security testing and
risk analysis. One central finding emphasizes the importance of testing particular vendor
implementations according to our two testing categories: adherence to functional security
design and proper behaviour under particular attacks motivated by security risks.
The latter category, adversarial security testing (linked directly to risk analysis findings),
ensures that cards can perform securely in the field even when under attack. Risk analysis
results can be used to guide manual security testing. As an example, consider the risk that, as
designed, the object-sharing mechanism in Java Card is complex and thus is likely to suffer
from security-critical implementation errors on any given manufacturer’s card. Testing for
this sort of risk involves creating and manipulating stored objects where sharing is involved.
Given a technical description of this risk, building specific probing tests is possible

Automating Security Testing
Over the years, Cigital has been involved in several projects that have identified architectural
risks in the GP/Java Card platform, suggested several design improvements, and designed
and built automated security tests for final products (each of which has multiple vendors).
Several years ago, we began developing an automated security test framework for GP cards
built on Java Card 2.1.1 and based on extensive risk analysis results. The end result is a
sophisticated test framework that runs with minimal human intervention and results in a
qualitative security testing analysis of a sample smart card. This automated framework is
now in use at MasterCard and the U.S. National Security Agency.
The first test set, the functional security test suite, directly probes low-level card security
functionality. It includes automated testing of class codes, available commands, and crypto
functionality. This test suite also actively probes for inappropriate card behavior of the sort
that can lead to security compromise.
The second test set, the hostile applet test suite, is a sophisticated set of intentionally
hostile Java Card applets designed to probe high-risk aspects of the GP on a Java Card
implementation.
Contd...

LOVELY PROFESSIONAL UNIVERSITY 143