Authentication framework for smart cards

• US 20040088562A1
• Filed: 10/31/2002
• Published: 05/06/2004
• Est. Priority Date: 10/31/2002
• Status: Abandoned Application

• Current Assignee: Axalto S A
• Original Assignee: Schlumberger Holdings Corporation (Schlumberger NV)
• Inventors: Hutchinson, Michael D., Vassilev, Apostol T.
• Application Number:
  US10/285,654
• Publication Number:
  US 20040088562A1
• Time in Patent Office: Days
• US Class Current: 713/200
• CPC Class Codes: G06F 21/34 involving the use of external additional devices, e.g. dongles or smart cards
• CPC Class Codes: G06Q 20/341 Active cards, i.e. cards including their own processing means, e.g. including an IC or chip
• CPC Class Codes: G06Q 20/3552 Downloading or loading of personalisation data
• CPC Class Codes: G06Q 20/40975 using encryption therefor
• CPC Class Codes: G07F 7/1008 Active credit-cards provided with means to personalise their use, e.g. with PIN-introduction/comparison system

Abstract

A smart card authentication framework may include a card application applet (CAA), an authentication policy applet (APA), and an authentication technology applet (ATA). The CAA may provide a protected service for a user. The APA may provide an authentication-technology-independent user validation service for the CAA. The ATA may provide a technology-specific authentication service. In one embodiment, the CAA provides a first external interface, the ATA provides a second external interface and a first internal interface, and the APA provides a second internal interface. The ATA may receive a host request for user authentication via the second external interface, and the ATA may process the authentication request without participation by the CAA. The CAA may communicate with the APA via the first internal interface to determine whether the user is currently validated. If so, the CAA may provide the protected service for the host via the first external interface.

Claims

1. A smart card that features a generalized authentication framework, the smart card comprising:

processing resources including memory and an instruction processor;

an authentication technology applet (ATA) stored in the memory;

authentication data stored in the memory as part of the ATA;

authentication instructions within the ATA that receive user input from a host via a first application protocol data unit (APDU) interface, authenticate user identity based on the authentication data and the user input, and return an authentication result to the host via the first APDU interface;

an authentication policy applet (APA) stored in the memory;

a card application applet (CAA) stored in the memory, wherein the CAA communicates with the host via a second APDU interface, and the CAA enforces security according to a predefined user role;

security configuration data stored in the memory as part of the APA, wherein the security configuration data includes security configurations that define relationships between user roles for CAAs and corresponding authentication requirements, and wherein at least one of the security configurations associates the predefined user role for the CAA with an application identifier (AID) for the ATA;

the APA including an internal interface, wherein the APA receives a call for role validation from the CAA via the internal interface, and the APA provides a gateway between the CAA and the ATA, such that;

in response to receiving the call for role validation, the APA accesses the security configuration data to identify the ATA associated with the predefined user role for the CAA;

in response to identifying the ATA, the APA communicates with the identified ATA to obtain an authentication status;

in response to obtaining the authentication status, the APA uses the authentication status and the authentication requirements for the predefined user role to determine a role validation result;

in response to determining the role validation result, the APA returns the role validation result to the CAA; and

the user input for user authentication does not pass through the CAA.

2. A smart card that features a generalized authentication framework, the smart card comprising:

an authentication technology applet (ATA) that provides a technology-specific authentication service;

an authentication policy applet (APA) that provides a technology-independent authentication service; and

a card application applet (CAA) that uses the technology-independent authentication service provided by the APA.

3. The smart card of claim 2, wherein the technology-independent authentication service provided by the APA comprises implementation of a technology-independent authentication policy.

4. The smart card of claim 2, wherein the APA provides the technology-independent authentication service based on a predefined role associated with the CAA.

5. The smart card of claim 2, wherein the ATA provides the technology-specific authentication service based on a personal identification number (PIN) authentication technology.

6. The smart card of claim 2, wherein the ATA provides the technology-specific authentication service based on a biometric authentication technology.

7. The smart card of claim 2, further comprising:

processing resources including memory and an instruction processor; and

wherein;

the memory contains the CAA, the APA, and the ATA;

the CAA provides a protected service for a user;

the CAA provides a first external interface for communication with a host;

the APA provides an internal interface;

the ATA provides a second external interface;

the CAA communicates with the APA via the internal interface to determine whether the user is currently validated;

the CAA provides the protected service for the host via the first external interface if the user is currently validated; and

if the user is not currently validated, the ATA receives a host request for user authentication via the second external interface, such that the host request for user authentication may be processed by the ATA without participation by the CAA.

8. The smart card of claim 7, wherein:

the memory contains computer instructions that, when executed by the instruction processor, provide a Java card runtime environment (JCRE);

the JCRE provides an application firewall that separates the CAA, the APA, and the ATA;

the first and second external interfaces comprise Java application protocol data unit (APDU) interfaces; and

the internal interface comprises a sharable interface.

9. The smart card of claim 7, wherein the CAA performs further operations comprising:

in response to determining that the user is not currently validated, returning a current validation state to the host via the first external interface, together with an application identifier for the host to use for communicating with the ATA.

10. The smart card of claim 7, wherein:

the internal interface provided by the APA comprises a first internal interface;

the ATA provides a second internal interface;

in response to receiving a validation call from the CAA via the first internal interface, the APA communicates with the ATA via the second internal interface to obtain data that indicates whether the user is currently authenticated; and

the APA determines whether the user is currently validated, based on the data that indicates whether the user is currently authenticated.

11. The smart card of claim 7, wherein:

the memory contains user authentication data;

the ATA determines whether the user is currently authenticated, based on the user authentication data and input data received from the host via the second external interface;

the APA comprises a security configuration for the CAA; and

the APA determines whether the user is currently validated, based on the data that indicates whether the user is currently authenticated and the security configuration for the CAA.

12. The smart card of claim 7, wherein:

the APA comprises a security configuration that associates the CAA with first and second ATAs, wherein the first and second ATAs utilize different authentication technologies;

the memory contains user authentication data for each of the first and second ATAs; and

the APA determines whether the user is currently validated, based on data from first ATA indicating whether the user is currently authenticated and data from the second ATA indicating whether the user is currently authenticated, according to the security configuration for the CAA.

13. The smart card of claim 7, wherein:

the CAA comprises one CAA among multiple CAAs stored in the memory;

the ATA comprises one ATA among multiple ATAs stored in the memory; and

the memory further comprises one or more data structures with data that encodes relationships comprising;

relationships between the CAAs and user roles; and

relationships between the user roles and the ATAs.

14. The smart card of claim 7, further comprising:

one or more security configurations, stored in the memory, that define one or more user roles and one or more corresponding authentication requirements.

15. The smart card of claim 7, wherein:

the APA further provides a third external interface for receiving personalization commands for defining a security configuration; and

the APA provides validation for the CAA, based on the security configuration.

16. The smart card of claim 15, wherein the APA allows the security configuration to be modified and functionality of the CAA to be retained without modifying the CAA.

17. The smart card of claim 7, wherein:

the ATA provides the APA with a Boolean user authentication result; and

the APA provides the CAA with a Boolean role validation result.

18. The smart card of claim 2, wherein the smart cad supports multiple concurrent validations for different host applications.

19. A method for enforcing user validation in a smart card with a generalized authentication framework, the method comprising:

using an authentication technology applet (ATA) to provide a technology-specific authentication service;

using an authentication policy applet (APA) to provide a technology-independent authentication service; and

using the technology-independent authentication service provided by the APA at a card application applet (CAA) to determine user validation.

20. The method of claim 19, wherein the technology-independent authentication service provided by the APA comprises implementation of a technology-independent authentication policy.

21. The method of claim 19, further comprising:

associating a role with the CAA; and

wherein the operation of using the APA to provide the technology-independent authentication service comprises using the role associated with the CAA to provide the technology-independent authentication service.

22. The method of claim 19, wherein the operation of using the ATA to provide the technology-specific authentication service comprises:

providing authentication based on a personal identification number (PIN) authentication technology.

23. The method of claim 19, wherein the operation of using the ATA to provide the technology-specific authentication service comprises:

providing authentication based on a biometric authentication technology.

24. A method for enforcing user validation in a smart card with a generalized authentication framework, the method comprising

communicating from a card application applet (CAA) to a authentication policy applet (APA) via an internal interface of the APA to determine whether a user is currently validated;

if the user is currently validated, providing a host with a protected service from the CAA via an external interface of the CAA;

if the user is not currently validated, receiving a host request for user authentication at an authentication technology applet (ATA) via an external interface of the ATA; and

processing the host request for user authentication at the ATA without participation by the CAA.

25. The method of claim 24, for use in a smart card with a Java card runtime environment (JCRE) that provides an application firewall which separates the CAA, the APA, and the ATA, wherein:

the operation of communicating from the CAA to the APA via the internal interface of the APA comprises communicating with the APA via a Java sharable interface of the APA;

the operation of providing the host with the protected service comprises communicating with the host via a Java application protocol data unit (APDU) interface of the CAA; and

the operation of receiving the host request for user authentication comprises receiving the host request for user authentication via an APDU interface of the ATA.

26. The method of claim 24, further comprising:

in response to determining that the user is not currently validated, returning a current validation state to the host via the external interface of the CAA, together with an application identifier for the host to use for communicating with the ATA.

27. The method of claim 24, further comprising:

in response to receiving a validation call at the ATA from the CAA via the internal interface of the APA, communicating from the APA to the ATA via an internal interface of the ATA to obtain data that indicates whether the user is currently authenticated; and

determining at the APA whether the user is currently validated, based on the data that indicates whether the user is currently authenticated.

28. The method of claim 24, further comprising:

determining at the APA whether the user is currently validated, based on a security configuration in the APA that defines a user role and a corresponding validation requirement for the CAA, and based on data from the ATA that indicates whether the user is currently authenticated.

29. The method of claim 28, further comprising:

receiving a command from the host via an APDU interface of the APA; and

in response to the command from the host, modifying the security configuration to associate a new ATA with the CAA, without modifying or disabling the CAA.

30. The method of claim 24, further comprising the operation of supporting multiple concurrent validations for multiple host applications.

32. The program product of claim 30, wherein the operations performed by the computer instructions further comprise:

receiving a command from the host via an APDU interface of the APA; and

in response to the command from the host, modifying the security configuration to associate a new ATA with the CAA, without modifying or disabling the CAA.

31. A program product that provides an authentication framework for a smart card, the program product comprising:

a computer-usable medium; and

computer instructions encoded in the computer-usable medium, wherein the computer instructions, when executed by a processor in a smart card, perform operations comprising;

communicating from a card application applet (CAA) to an authentication policy applet (APA) via an internal interface of the APA to determine whether a user is currently validated;

if the user is currently validated, providing a host with a protected service from the CAA via an external interface of the CAA;

if the user is not currently validated, receiving a host request for user authentication at an authentication technology applet (ATA) via an external interface of the ATA; and

processing the host request for user authentication at the ATA.