Patent Application
20070192840
The present invention relates to a secure element and a mobile communication apparatus comprising such a secure element. The invention further relates to a user interface and an apparatus comprising the user interface. In particular, the invention relates to controlling resources such that they are not revealed outside the secure element unless a user identification is authenticated.
Personal mobile devices, such as a mobile phone, may contain security sensitive personal applications and data, such as credit card data. Most of the time the mobile device is in the possession and control of its owner. However, occasionally the mobile device may be given to other people for use, usually for a short period of time. Additionally there may arise a need to give the mobile device to a third party for a longer period of time, e.g. for maintenance. In such cases it would be desirable that the owner of the mobile device can make these personal applications disabled while the mobile device is not in the possession of the owner.
A method an apparatus for secure leveled access control is disclosed in WO 02/33521 A2, which is hereby incorporated by reference. The method and apparatus are arranged to disable functions of processing circuits until an authentication process is successful. The authentication is performed by a key corresponding to the desired function.
In view of the above, an objective of the invention is to further reduce the amount of personal information that can be obtained from the mobile device.
According to a first aspect of the present invention, there is provided a secure element with capability of securely storing security sensitive data. The secure element comprises data related to at least one resource, and a user authentication means, wherein existence of the at least one resource is not revealed outside the secure element unless an approved user identification related to the resource is authenticated by the user authentication means. Thereby, applications are not only disabled, they are not revealed outside the secure element, and can thus not be identified, which substantially reduces the risk of information leakage. In short, it is harder to break into something that you are not aware that it exists. In addition to that, there is also information in that you are in the possession of a resource, but with the present invention, this information is not available unless an approved relation exists and is proven between the user and the resource.
The secure element may comprise an operating system for controlling operation of the at least one resource, and reception and authentication of the user identification. Having a secure element having its own operating system further improves security. The sucure element may be a smart card. Examples of smart cards that may be used are Java card with Global Platform functionality, UICC, EMV, PKI, etc. Other examples are SIM cards for telephones, cash and bonus cards, etc.
The at least one resource may comprise an application and the data is adapted for execution of the application. The at least one resource may comprise a plurality of applications, where each application is associated with a separate password. Alternatively, all applications may be associated with a common password. The plurality of applications may be grouped into a plurality of application groups, where each application group is associated with a separate password.
The at least one resource may comprise a data item and the data is adapted for providing the data item to an application. The at least one resource may comprises a plurality of data items, where each data item may be associated with a separate password. Alternatively, all data items may be associated with a common password. The at least one resource may comprise a plurality of data items being grouped into a plurality of data item groups, where each data item group is associated with a separate password.
According to a second aspect of the present invention, there is provided a mobile communication apparatus comprising a secure element according to the first aspect of the invention.
In the mobile communication apparatus, the user identification may be enabled to be entered as a personal identification number.
The at least one resource may comprise an internet banking application, a contact item, an applet, a media file, or a security code item, or any combination thereof.
According to a third aspect of the present invention, there is provided a user interface arranged to display a first set of resources and, upon authentication of an approved user identification, to display a second set of resources, wherein said second set of resources comprises at least one resource associated with security sensitive data. The resources may comprise similar features as those described for the first aspect of the present invention. At least one of said at least one resource associated with security sensitive data may correspond to a resource without association to said security sensitive data in said first set of resources.
According to a fourth aspect of the present invention, there is provided an apparatus comprising a user interface according to the third aspect of the present invention.
Generally, all terms used in the claims are to be interpreted according to their ordinary meaning in the technical field, unless explicitly defined otherwise herein. All references to “a/an/the [element, device, component, means, step, etc]” are to be interpreted openly as referring to at least one instance of said element, device, component, means, step, etc., unless explicitly stated otherwise. The steps of any method disclosed herein do not have to be performed in the exact order disclosed, unless explicitly stated.
Other objectives, features and advantages of the present invention will appear from the following detailed disclosure, from the attached dependent claims as well as from the drawings.
The above, as well as additional objects, features and advantages of the present invention, will be better understood through the following illustrative and non-limiting detailed description of preferred embodiments of the present invention, with reference to the appended drawings, where the same reference numerals will be used for similar elements, wherein:
a and 3b show an apparatus with a user interface according to an embodiment of the present invention; and
a and 4b show an apparatus with a user interface according to an embodiment of the present invention.
The mobile communication apparatus 100 further comprises a secure element 122 having capability of securely storing security sensitive data and processing internal transactions with the data, e.g. payment transactions, key generation, etc. This capability implies that certain data stored in the secure element 122 is only accessible by the processor 102 upon proven access to the data. Further, some data stored in the secure element 122 is only allowed to be processed inside the secure element 122. Examples of this is the access check to data that is to be provided to the processor 102, or generation of keys. The secure element can be a smart card, e.g. a Java, UICC, EMV, PKI, or SIM card, or a protected circuit in the mobile communication apparatus 100, e.g. a microprocessor with internal read-only-memory and a protected static random access memory, or a protected part of the processor 102.
A typical deployment scenario can be such that one resource is a smart card application, which contains data and additional functions to process this data, either solely internally, or internally and externally. Note that there can be more than one resource, e.g. application or function. Authentication schemes according to the invention either hide these resources or makes them visible. When hidden, the resources cannot be accessed in any way. Even when the resources are in a visible state, each resource may still implement additional authentication mechanisms, which are not a part of the authentication for hiding and revealing of resources.
Returning to
For the resources of the secure element, which are to be revealed only after proper authentication of the user, it is preferred that the view that the user interface presents to the user is not changed for other resources, which are not part of the protected resources of the secure element or other resources of the secure element that has been made available by proper authentication. This applies for example to short cut keys to applications, speed dialing, menu items, etc. For lists of resources, the unavailable resources are simply not present in the lists.
An apparatus 300, 400 provided with such a user interface is preferably provided with a display 302, 402 that is capable of displaying a plurality of items 304a, 304b, or the apparatus is able to scroll between a plurality of items 404a, 404b for viewing on the display, as is illustrated by
For graphical user interfaces using e.g. icons, the icons of the unavailable resources are not shown, and the other icons can either remain in their original positions. Thus, as Illustrated by
Alternatively, as illustrated in
As demonstrated by the examples, illustrated by
An issuer of the secure element, which can be considered as a trusted party, can be in possession of cryptographic keys enabling certain management operations of the secure element. Thereby, management, such as updating, unlocking the secure element, etc. can be provided to the secure element by the trusted party. This can then be performed by an issuer key, which is one or more keys stored in the secure element and controlled by the issuer. Thus, in addition to the authentication, that can be based on a password or cryptographic key provided by a user or another authentication element, there can be provided a further level of authentication based on a password or key provided by the issuer of the secure element.
The authentication can be based on a password, with which user can set the applications of the secure element to be invisible, and by re-entering this password the applications become visible again on the user interface. Switching between visible and invisible stages does not impact the actual applications in any way, and no modifications would be needed to these applications. In order to protect against password attacks a maximum number of password attempts is defined and this value may be configurable. Here, the issuer can have the capacity to switch the invisible stage back to visible stage and to reset the password to some initial default value, e.g. when the password has been locked after too many incorrect attempts. Both these actions require the issuer key(s) to be used to authenticate securely between the secure element and the issuer.
The described invention can be deployed to a smart card chip with smart card operating system, such as Java smart card with Global Platform, or to similar security hardware devices. The following description focuses on Global Platform Java smart card, but as stated above, the solution is of general nature and thus can be applied for other smart card implementations and to other security hardware devices too.
One implementation scenario of the invention will now be described, where the resources are described as applications and the authentication to be performed with a password for the sake of clarity. However, what is her described is also applicable to other resources such as data items, and the authentication can be performed in any of the above described manners.
In a normal stage of the secure element, in this case Java smart card with Global Platform functionality, all applications are visible to the external world and usable as defined for each application. It may be that specific applications in the secure element are associated with application specific password, such as personal identification number (PIN), while some other applications may be freely usable without any user authentication. This kind of visibility of the specific applications potentially gives unnecessary information to third parties, e.g. to others than the owner, having access to the mobile device. This is solved by an additional password concept to protect the secure element access by making these specific applications invisible to the external world, i.e. outside the secure element and in particular through the user interface.
The operating system of the secure element implements a visibility password. There can be a pre-defined initial default value for the visibility password, e.g. “0000”. The visibility password is managed by the user and thus can be changed by the user upon proper authentication.
The operating system can have the following stages in respect to the application visibility and the visibility password:
OK_Visible; The applications are visible and can be accessed and used as in the normal stage. The visibility password is defined, either by the initial value or another value defined by the user, and unlocked
OK_Invisible; The applications are invisible and cannot be accessed or used. The visibility password is defined, either by the initial value or another value defined by the user, and unlocked
Locked_Invisible; The applications are invisible and cannot be accessed or used. The visibility password is locked and cannot be used
The operating system can implement the following additional operations:
Set_Visibility_Password; The Visibility Password can be set to a new value, for which action the correct current visibility password has to be provided to the operating system. Preferably, this command can be executed only in the OK_Visible stage
Make_Invisible; This operation makes the applications invisible and sets the operating system stage to OK_Invisible. The correct visibility password has to be provided to the operating system as part of this operation. Preferably, this operating can be executed only in the OK_Visible stage
Make_Visible; This operation makes the applications visible and sets the operation system stage to OK_Visible. The correct visibility password has to be provided to the operating system as part of this operation. Preferably, this operation can be executed only in the OK_Invisible stage
Request_OS_stage; This operation returns the information about the operating system stage
Reset_Visible; If the visibility password is locked, the operating system stage will be set automatically to Locked_Invisible. Only the issuer can reset the visibility password back to initial default value and set the operating system stage to OK_Visible with this operation. The operation comprises a mutual authentication with the secure element Issuer Security Domain (ISD) key. The issuer has the ISD Master Keys, from which the secure element specific ISD keys are derived by using a unique serial number, or any other identifier, of the secure element as the diversification element. The unique serial number is publicly readable even in the Locked_Invisible and OK_Invisible stages. This command can also be used in the other two operating system stages, i.e. OK_Visible and OK_Invisible.
The operating system stage is set to Locked_Invisible if the number of incorrect visibility password attempts exceeds a maximum number of allowed attempts.
Java is a trademark or registered trademark of Sun Microsystems, Inc. in the United States and other countries.
The invention has mainly been described above with reference to a few embodiments. However, as is readily appreciated by a person skilled in the art, other embodiments than the ones disclosed above are equally possible within the scope of the invention, as defined by the appended patent claims.
