Tuesday, August 26, 2008

What do you mean by SCMS ?

As I was on holidays, I discussed my current job with an old friend. In the middle of the conversation my friend said to me you always speak about "Smart Card Management System" (SCMS), but what do you really mean by that ? So I explain what I meant by a SCMS to him.

Back on my computer, I wanted to check my interpretation of a SCMS. What I expected to be fairly straightforward didn't turn out to be the case. I think this confusion is best summarized in this quote from Frost & Sullivan "The definition of a SCMS is found to vary depending on its use or application. In general, a SCMS must be able to provide information on the different applications present on a card. This refers to the application’s expiration, the application’s access for a particular project, the type of data that can be viewed by individuals and so on. Another key aspect of any SCMS is to provide post issuance capabilities. This allows for other applications to be added on to a card."

In fairness the first sentence of this quote does well reflect the current situation, when we are all talking about SCMS, we are not talking about the same things. If you are not convinced do a search on the web... Or are we?

Well, it is time to get back to basic and use of one of the most commonly accepted definitions of a system "A system is a set of objects together with relationships between the objects and between their attributes." (in 'Definition of System' by Hall and Fagen, 1956).

So it is time to try and describe a SCMS, as in the quote from Frost & Sullivan, following this definition. A SCMS is a set of objects: Card Image Database[1], Card Personalisation System[2], Data Preparation[3] and Key Management[4], Post-Issuance Server[5], Card Management Server[6]... Wait, a minute here is one of the paradox we are facing. We are using the SCMS terminology for the whole system and one of its part - the Card Management Server. The next contreversial aspect is the application data, this often handled inconsistently. For example, in the above quote, consideration is given in terms of application data that can be viewed but post-issuance is limited to adding application on the card and not data application update. Then depending on the market where such SCMS are deployed, other features such as cardholder data or EMV parameters might be included. Those topics subject to interpretation have created the situation in which there isn't a clear definition of a SCMS.


I think there is merit in attempting to adopt a common definition of a SCMS, similar to what a RDBMS or an Application Server is. I think the SCMS should not manage cardholder or application data, this is best left to other systems. However the SCMS should be capable of performing any personalisation either during issuance or post-issuance using those data. The SCMS doesn't attach any semantics to those data, it handles them as opaque blob according to specified syntax rules regarding their format, encoding, length, type... As for removing the confusion between the whole system and its part maybe it is time to re-introduce the Card Life Cycle terminology to describe what the Card Management Server does.

[1] That provides persistence storage

[2] That performs chip and magnetic stripe encoding and card surface printing, embossing and lamination

[3] That retrieves data from the Card Image Database and External Application and formats it for personalisation (Issuance and Post-Issuance) purposes.

[4] That provides secure persistent key storage, cryptographic services using those keys and key exchange and configuration.

[5] That supports secure post-issuance personalisation, authenticating the card and performing card updates (usually chip encoding).

[6] That provides interfaces to external systems and users and control the status and operations those systems attempts to perform on the card delegating keys and cyrytpographic operations and personalisation to other systems (KMS and SCPS)

No comments: