If all applications could be loaded at the start this would boil down to information flow analysis for which many solutions exist, but this is precisely what we want to overcome. When applications are not known in advance and can be updated asynchronously and possibly without connection to trusted third parties, we must preserve the security policies of the various owners of the applets during such autonomous evolution. This chapter illustrates the extension of the Security-by-Contract approach from mobile phones to smart cards: Security-by-Contract is based on the loading time application certification on the card that will enable the card to make autonomous decisions on application and policy updates while ensuring the compliance of every change of the platform with the security policy of each application’s owner.
TopIntroduction
Smart cards are one of the most widespread computing platforms today. Indeed, we use them as banking cards, healthcare cards, transport and loyalty cards, security tokens, etc. Already in 2006 there was more than 100 millions non-GSM (global platform) cards (GlobalPlatform, 2007). By 2010 the numbers have increased to the order of billions only in terms of EMV1 cards without counting GSM/UMTS cards and other e-health or transport cards in place in almost all European Countries (SecureIDNews, 2010). Actually, we have too many cards in our wallets. The industry noticed this fact long time ago, and already in the 90s various standards for multi-application cards have emerged, including Java Card (Sun Microsystems, 2006), MULTOS (MULTOS Consortium, 2009), and GlobalPlatform (GP) (GlobalPlatform, 2006).
Paradoxically, though the standards we have mentioned were developed intentionally for maintaining applets from different stakeholders on the same platform, most multi-application solutions we have today consist of applets coming from the same provider. These are usual combinations of transport and electronic purse, or multi-functional identity cards issued by governments. One of the reasons behind the rare deployment of open multi-application cards is the difficulty that the various application providers experience while trying to join existing smart card solutions (Dusart, 2008), (Akram, 2010a). It is actually easier for them to issue their own cards than to negotiate joint card issuance.
There is also another problem – the interactions of the applets on the card. Since a smart card platform is a secure device, it seems natural to implement the interactions of the applications (for instance the transport – electronic purse tandem) on the card, where protection from eavesdropping would be ensured by default. For Java Card that would be done by calling methods implementing Java Shareable interface (we consider Java Card as the most common solution).
Consider the standard example of Lufthansa – EMV card (Miles&More), where the Lufthansa loyalty applet and standard credit applet from some bank reside. It seems it would be a perfect case for multi-functional platform, where the loyalty applet could have an access to some service (method implementing Shareable interface) of banking application, thus counting additional miles for each euro spent by the cardholder. But in reality data exchanges happen through the databases outside the card and not on the platform.
The situation is more complicated by the fact that the applications on the card could be updated, since the same standards of Java Card or MULTOS support this possibility as well. The problem is that the manufacturers can certify the cards (platform with all the applications) for the compliance of Common Criteria or another security standard (Chetali, 2008), (Narasamdya, 2009), (Dusart, 2008). But if any security-relevant change occurs on the platform, the certificate is broken and the card may require expensive re-certification.
For open multi-application cards, where the applets come from different providers, each update will require a complicated negotiation with every stakeholder. Of course, Lufthansa does not want to go to the bank each time it wants to change a piece of its applet. But with the current security mechanisms on the cards, there is just no other way. In Java Card all application interactions are mediated by the firewall (Chen, 2000). If application A wants to use some service s of another application B, it pings the firewall, which, in turn, will ask B if it is willing to grant A an access to s. Basically, B has an access control list embedded into its code with the identifiers (AIDs) of the applets it may grant access. Then, if A is in this list, the firewall responds to A with a reference to s, otherwise it will respond with null. The access control may be performed once or each time some service is requested. Anyway, in the dynamic setting, B cannot be sure that A is still the same A that is trusted, or it has been updated and cannot be trusted anymore. Consequently, the owners of A and B have to negotiate each time they want to update their applets and have to prove their good intentions.