On the road to Bandol

One of Bandol’s major innovations is the adoption of the servlet programming model. This can be considered as an acknowledgement by the smart card industry of the role of secure personal server for smart cards. Now, we just have to make sure that issuers share that vision.

On technical matters, we are faced with the classical issue. As we are adapting an existing framework to smart cards, how far should we go in ensuring that we can program smart cards like other machines? Are there any significant differences? One of the issues is here access control. Will smart card servlets require standard servlet access control, or will they require a different model?

This is an ongoing Java Card Forum discussion. Of course, I will not disclose the discussion here, and I just want to outline a few ideas and doubts that I have about this debate.

The basic temptation is to believe that developers work for themselves, and that they will use the same applications on classical Web servers and on smart cards. This is extremely unlikely, for two main reasons:

• The way in which applications are deployed on smart cards makes developers highly dependent on issuers (possibly, application providers). Nevertheless, their degree of freedom is very limited, and they will have to deal with many issues such as backward compatibility and other fun stuff that will make the adoption of any new model (and in particular of a security model) difficult.
• Smart cards are likely to remain quite specific platforms. For instance, the way in which persistence is achieved is likely to make developers write specific versions of their applications. Limited resources and APIs will do the rest.

This does not mean that adapting other frameworks is useless. It has several interesting uses. First, by reusing a well-known framework, we significantly reduce the chances of making bad design mistakes, because the framework has already been tested. Then, reusing another framework allows us to also reuse the tools developed for this framework.

The main issue is here declarative security. To make complicated things simple, declarative security works in three simple steps:

1. Each user (cardholder or remote user) is associated to a given role.
2. Each role is given some access rights.
3. Rights are checked in a generic way during the processing of a request.

The approach has numerous advantages. The most interesting one is that it makes the access control part of security orthogonal to the code (roles and rights are declared in a descriptor, not in the code itself; the code only checks that “declarative security is OK”).

The big question is: does this apply to smart card applications? There is no definitive answer, but there are at least two important points to consider:

• Security is at the core of smart card applications. For most smart card applications, security is a key feature, and one of the major objectives. This means that most security decisions are taken early in the process, and security is part of the application’s specification. In such cases, orthogonality is not that useful. In addition, if there is any kind of backward compatibility issue, it is most likely inapplicable.
• The association of users to roles is usually managed directly by smart card applications, using complex and often proprietary authentication schemes. This may change with Web server applications, but somehow I can’t completely convince myself. One example is the application provider authentication mechanism provided by GlobalPlatform (secure channel). Although this mechanisms matches quite well the requirements from smart card applications, itis seldom used in actual applications, except for the proprietary personalization phase.

The second argument is for me the most significant one. Smart card applications are likely to require strong user authentication. In particular, cryptographic mutual authentication and the establishment of some kind of secure channel is likely for remote users.

We need to make sure that whatever decision we make, we will be able to accomodate what the developers and application providers will invent. With smart card Web servers, we don’t have to deal with much history and backward compatibility. This is a good thing, as it removes many constraints; on the other hand, it gives us the responsibility of ensuring that we are not taking bad decisions that we will need to carry with us for many years.