A Dynamic and Ubiquitous Smart Card Security Assurance and Validation Mechanism

Abstract

Abstract. Smart cards have been deployed as trusted components in a wide range of industries. The basis of the trust on a smart card platform and applications is static and evaluated before the card issuance to cardholders. A dynamic and post-issuance security assurance and validation mechanism can be useful, but it is not considered necessary in the Issuer Centric Smart Card Ownership Model. However, in an open and dynamic smart card environment like the User Centric Smart Card Ownership Model, it is essential to have a mechanism that on request could provide assurance and validation of the implemented and evaluated security mechanisms. Such a framework is the focus of this paper.

Coopetitive Architecture to Support a Dynamic and Scalable NFC Based Mobile Services Architecture

“…The attestation handler implements the security-assurance and validation mechanism that certify to the requesting entity (e.g. Service Provider: SP) that the smart card's state is as it was at the time of a third party evaluation and stated by the evaluation certi cate [11]. An evaluation certi cate is a cryptographically signed certi cate issued by an evaluation body, and the respective card manufacturer places it on the platform.…”

User Centric Security Model for Tamper-Resistant Devices

“…limited scalability regarding the support for di erent application and platform scenarios, e) do not provide dynamic trust validation and assurance [56] and require an implicit trust, f ) do not require third party (security) evaluation, and g) do not provide user ownership/control (e.g. smart cards [32]).…”

“…It only gives the assurance that the smart card is secure against attacks as evaluated by the third party and stated in the issued certi cate [56], and that it is a state-of-the-art tamper-resistant device at the time of evaluation. Therefore, if the evaluation certi cate does not meet the SPs requirements or it out-dates the current attacker capability then the SP should decline the application lease.…”

“…The applications have no in uence on the outcome of the hash generation; so they cannot fake their current state. If the current state is considered to have deviated from the stated secure state in the application certi cate [56], the recipient can then decide whether to continue the protocol or not.…”

“…This assumption that centralised control guarantees security led to a realistic but simple approach to numerous smart card security mechanisms; such as the smart card rewall [82], application installation mechanism/protocol [83], virtual machine [84] and platform assurance [56,85,86]. Costly.…”