DE112013004444T5 - Method and device for managing data in a secure element - Google Patents

Abstract

Apparatus and methods for managing and sharing data across multiple access control clients in devices are disclosed herein. In one embodiment, the access control clients include Electronic Subscriber Identity Modules (eSIMs) arranged on an embedded Universal Integrated Circuit Card (eUICC). Each eSIM contains its own data. An Advanced Subscriber Identity Toolkit application maintained in the eUICC makes it easy to manage and share data from multiple eSIMs for different purposes, such as: Sharing phone book contacts or facilitating automatic switching between the multiple eSIMs (such as based on user context).

Description

Field of the invention

The present invention relates generally to the field of communication systems and, more particularly, in an exemplary aspect, to facilitate sharing of data between multiple user access clients on one or more mobile devices.

Description of the related technology

Access control is required for secure communication in most prior art wireless radio communication systems. For example, a simple access control scheme may include: (i) verifying the identity of a communicating party, and (ii) granting an access level corresponding to the verified identity. In the context of an exemplary cellular system (e.g., Universal Mobile Telecommunications System (UMTS)), access control is governed by an access control client referred to as a Universal Subscriber Identity Module (USIM) operating on a Universal Universal Integrated Circuit Card (FIG. UICC) (also referred to as "SIM card") expires. The USIM Access Control Client authenticates the subscriber to the UMTS cellular network. After a successful authentication, the subscriber is allowed to access the cellular network. As used herein, the term "access control client" generally refers to a logical entity embodied either in hardware or software or combinations thereof, capable of controlling the access of a first device to a network. Known examples of access control clients include the aforementioned USIM, CDMA Subscriber Identification Module (CSIM), IP Multimedia Services Identity Module (ISIM), Subscriber Identity Module (SIM), Removable User Identity Module (RUIM), etc. Traditionally, the UICC sets a trusted limit for one or more USIM (or more generally "SIM") access control clients. The UICC is manufactured and "hard-coded" with a SIM, i. H. Once programmed, the UICC can not be reprogrammed. If a user wants to authenticate to a cellular network using another SIM, the user must physically exchange the SIM card in the device for a different SIM card. In response to these physical limitations, some devices have been developed that can simultaneously accommodate two SIM cards, known as dual SIM phones. However, dual-SIM phones do not address the fundamental physical limitations of SIM card devices. For example, the information stored within a SIM card can not simply be merged with information stored within another SIM card. Existing dual-SIM devices can not access the contents of both SIM cards simultaneously. Finally, accessing a SIM card requires a significant and non-trivial amount of time for the user; switching between SIM cards to transfer information is undesirable and reduces the user experience, and this limitation exists in both traditional and dual SIM devices.

Accordingly, new solutions are needed to increase the flexibility of accessing multiple access control clients. Ideally, such solutions should allow sharing of common user data between the multiple access control clients to enhance the user's experience. In addition, the improved methods and apparatus should allow for seamless switching between the multiple access control clients to improve user access and cellular service utilization.

Summary of the described embodiments

The present invention satisfies the above-mentioned needs by providing, inter alia, an improved apparatus and method for sharing data between multiple user access clients of one or more mobile devices.

In one aspect of the present invention, there is disclosed a secure element configured to store one or more access control clients, wherein each of the one or more access control clients includes data. In one embodiment, the secure element includes a secure processor and secure storage device in data communication with the secure processor. In an exemplary embodiment, the storage device includes computer-executable instructions configured to, when executed by the secure processor, receive a request to access first data of an inactive first access-control client, verify the request, to the first data of the inactive first access control client and return the first data.

In one variant, each of the one or more access control clients comprises computer-executable instructions configured to, when executed by the secure processor: receive a request, have an active second access control client of one To authenticate network entity; to authenticate the request; and if the request is authentic, responding to the network entity.

In another variant, requests to access data and requests originating from the network have different privilege levels.

In some variants, the request identifies a requester. For example, the requestor may be a user. In another example, the requestor may be a software application. In such a case, the software application resides on the secure element. In still other examples, the requestor includes a software process on a second one of the one or more access control clients on the secure element.

In a second aspect, a method of processing data within a secure element configured to store one or more access control clients, each of which includes data, is disclosed. In one embodiment, the method includes: receiving a request to access first data; Verifying the request; Searching a plurality of access control clients for the first data; and when the first data has been found, returning the first data.

In such a variant, verifying the request includes identifying the requester. In such an example, verifying the request further comprises determining a privilege associated with the requestor. In another example, the particular privilege associated with the requester is predetermined by an administrative entity.

In other variants, accessing the first data includes accessing a plurality of contact information to identify a single contact.

In still other variants, accessing the first data comprises accessing one or more device configurations, the access release configuration of a device according to at least one of the one or more configurations.

In a third aspect, there is disclosed a secure element configured to store one or more access control clients, wherein each of the one or more access control clients includes data. In one embodiment, the secure element comprises: means for receiving a request to access first data; Means to verify the request; Means for searching the one or more access control clients for the first data; and means for returning the first data.

In one variant, the means for verifying the request comprise means for verifying a personal identification number (PIN) or password provided by a user.

In other variants, the means for verifying the request comprises means for determining a software privilege level of a software application.

In still other variants, the secure element comprises means for receiving a network request to authenticate the access control client.

In a fourth aspect, a mobile device is disclosed. In one embodiment, the mobile device comprises: a secure element, wherein the secure element is configured to store one or more access control clients, each of the one or more access control clients containing data; one or more wireless communication circuits adapted to communicate with a communication network; a first processor; a memory device in data communication with the first processor, the memory device including computer-executable instructions configured to, when executed by the first processor, transmit a request to access first data of a first access control client according to a first privilege where the first privilege is restricted to data that can be accessed by a toolkit; wherein the request is configured to cause the secure element to: verify the request; accesses the first data of the first access control client; and returns the first data to the first processor.

In a fifth aspect of the present invention, a method of accessing data within a secure element of a user device is disclosed. In one embodiment, the method comprises: transmitting a request to access first data stored on the secure element of the user device; in response to receiving the request, verifying the secure element of the request by the secure element; if the request is valid, locating the first data on one of the plurality of access control clients; and receiving the first data from the secure element.

In a sixth aspect of the present invention, a mobile device is disclosed. In one embodiment, the mobile device comprises: a secure element, wherein the secure element is configured to store one or more access control clients, each of the one or more access control clients containing data; one or more wireless communication circuits adapted to communicate with a communication network; Logic configured to request access to first data of a first one of the one or more inactive access control clients stored on the secure element; wherein the secure element is configured to verify the request, and if the request is valid, provide the first data to the first access control client; and logic configured to receive the first data from the secure element.

Other features and advantages of the present invention will be readily appreciated by those skilled in the art with reference to the accompanying drawings and detailed description of exemplary embodiments as set forth below.

Brief description of the drawings

1 Fig. 3 graphically illustrates an example of an Authentication and Key Agreement (AKA) method using a USIM according to the prior art.

2 Figure 10 is a block diagram of an exemplary embodiment of a device useful for implementing the methods of the present invention.

3 FIG. 3 is a logical representation of an exemplary embodiment of an embedded Universal Integrated Circuit Card (UICC) according to various aspects of the present invention.

4 FIG. 3 is a logic flow diagram of one embodiment of a generalized method for managing data in a secure element in accordance with various aspects of the present invention. FIG.

5 FIG. 10 is a logical flow diagram of one embodiment of a method for merging user-defined contact information of multiple electronic subscriber identity modules (eSIMs) according to the present invention.

6 FIG. 10 is a logic flow diagram illustrating an embodiment of a method for searching for contact information in multiple electronic subscriber identity modules (eSIMs) in accordance with the present invention.

7 FIG. 3 is a logic flow diagram illustrating one embodiment of a method for facilitating automatic switching between Electronic Subscriber Identity Modules (eSIMs) based on user-defined conditional triggering in accordance with the present invention.

Detailed description of the described embodiments

Reference is now made to the drawings, wherein like reference numerals refer to like parts throughout.

Among other things, the present invention provides methods and apparatus for managing and sharing data across numerous user access control clients in devices. In one embodiment, an embedded Universal Integrated Circuit Card (eUICC), a secure element, or a UICC containing a logical entity (eg, an Advanced Subscriber Identity Toolkit) manages and provides access to data passing through multiple electronic subscribers Identity Module (eSIMs) are stored. For example, data can be created from user-defined data (UDD), such as As settings and data that have been configured by a user, such. Telephone book contacts, eSIM user preferences, etc.), operator specific data, calibration data, etc. The Advanced Subscriber Identity Toolkit provides a secondary privileged interface that enables faster access to data stored in the eSIM without compromising the integrity of eSIM security.

Still other aspects of the present invention enable collaborative operation of access control clients. For example, in an exemplary use case, a logical entity such as a. For example, the aforementioned Advanced Subscriber Identity Toolkit is configured to monitor operational and other conditions of a device and compare it to eSIM usage preferences that have been specified by a user (or, eg, a network operator, etc.). The exemplary implementation of the Advanced Subscriber Identity Toolkit can also automatically switch the active eSIM according to the desired preferences.

Exemplary embodiments and aspects of the present invention will now be described in detail. While these embodiments and aspects are primarily in the context of Subscriber Identity Modules (SIMs) of a GSM, GPRS / EDGE, or UMTS cellular network will be appreciated by those skilled in the art that the present invention is not limited thereto. In fact, various aspects of the invention are useful in any wireless network (whether cellular or otherwise) that can benefit from the secure management of multiple user access control clients.

It will also be appreciated that while the term "Subscriber Identity Module" is used herein (eg, SIM, USIM, CSIM, eSIM, etc.), this term by no means necessarily implies either (i) use by a subscriber per se (ie, the invention may be practiced by a participant or non-participant); (ii) the identity of a single individual (i.e., the invention may be used by a group of individuals, such as a family, or intangible or fictitious entities, such as a corporation); or (iii) any tangible "module" equipment or hardware, includes or requires.

Subscriber Identity Module (SIM) operation

In the context of prior art cellular UMTS networks, a user equipment (UE) comprises a mobile device and a Universal Subscriber Identity Module (USIM). The USIM is a logical software unit stored on and executed by a Universal Universal Circuit Card (UICC). A variety of information is stored in the USIM, such as: B. subscriber information as well as the keys and algorithms used to authenticate with the network operator to obtain the wireless network services. In some alternative implementations, the keys and / or cryptographic algorithms are stored in the UICC's operating system. The USIM software is based on the Java Card programming language. Java Card is a subset of the Java programming language that has been modified for "card" type embedded devices (such as the aforementioned UICC).

In general, UICCs are programmed with a USIM prior to distribution to the subscriber. Preprogramming or personalizing is specific to each network operator. For example, prior to use, the USIM is associated with an International Mobile Subscriber Identification (IMSI), a unique Integrated Circuit Card Identifier (ICCID), and a specific authentication key (K). The network operator stores the association in a register included in the authentication center (AuC) of the network. After personalization, the UICC can be distributed to the participants. Now referring to the 1 An exemplary Authentication and Key Agreement (AKA) method is illustrated in detail using the aforementioned USIM of the prior art. During normal authentication procedures, the UE receives the International Mobile Subscriber Identification (IMSI) from the USIM. The UE forwards the IMSI to the serving network (SN) of the network operator or the visited core network. The SN forwards the authentication request to the AuC of the home network (HN). The HN compares the received IMSI with the register of the AuC and obtains the appropriate key K. The HN generates a random number (RAND) and signs it with the key K using an algorithm to generate the expected response (XRES). The HN further generates a Cipher Key (CK) and an Integrity Key (IK) for use in encryption and integrity protection as well as an Authentication Token (AUTN) that uses various algorithms. The HN sends an authentication vector consisting of the RAND, XRES, CK and AUTN to the SN. The SN stores the authentication vector only for use in a one-time authentication process. The SN gives the RAND and AUTN to the UE.

When the UE receives the RAND and AUTN, the USIM verifies that the received AUTN is valid. If so, the UE uses the received RAND to calculate its own response (RES) using the stored key K and the same algorithm that generated the XRES. The UE returns the RES back to the SN. The SN compares the XRES with the received RES and, if they match, the SN authorizes the UE to use the operator's wireless network services.

In addition to having the UICC programmed with a USIM, the UICC is generally programmed with other applications that provide enhanced functionality for the UICC. Common examples of such applications are a telephone book or a USIM Application Toolkit (USAT). The USAT is typically used as a value added service technology that extends the communication protocol between the UICC and the device.

Encryption / key schemes

Asymmetric key schemes use different keys to encrypt and decrypt messages, and therefore the encryptor and decryptor do not share the same key. Symmetric key schemes use the same key (or trivially transformed key) for both encryption and decryption. The Rivest, Shamir, and Adleman (RSA) algorithms are a type of public / private key pair cryptography is generally used in the art, but it will be appreciated that the present invention is by no means limited to the RSA algorithm. Public / private cryptographic schemes can be used to encrypt a message and / or generate signatures. Specifically, a message may be encrypted with a private key and decrypted with a public key, thereby ensuring that the message has not been altered at the transition. Similarly, a signature created with the private key can be verified with the public key, which ensures that the entity that generates the signature is legitimated. In both uses, the private key is kept hidden and the public key is distributed freely.

device

As a brief aside, the prior art UICCs (eg, a SIM card) may be moved freely between mobile devices, but the SIM itself is hard-coded in the UICC. While SIM cards can be preprogrammed with multiple SIMs (e.g., a USIM and a CSIM, etc.), existing developments generally include only a single SIM. According to existing SIM trust architectures, the mobile device is not a trusted entity; therefore, the SIM card must determine if the mobile device has been compromised before granting access. In fact, the SIM is only configured to establish confidential communications with a home network (HN) or a serving network (SN) that has access to appropriate cryptographic secrets.

In addition, there is no mechanism in existing solutions for authenticating a SIM card to another SIM card, so the "trust limit" of each SIM card is limited to the card itself. Sharing information between SIM cards requires that a mobile device can securely access each SIM card and externally transfer information between SIM cards.

In contrast, according to one aspect of the present invention, a secure element (UICC, eUICC, etc.) is configured to store multiple SIM elements, hereafter referred to as Electronic Subscriber Identity Modules (eSIM). Each eSIM is a software emulation of a typical USIM, and includes analog programming and related user data. In some variants, an eSIM may include additional software and / or applications in addition to the USIM applications. In an exemplary embodiment, an embedded UICC (eUICC) resident in a mobile device is configured for use with an Advanced Subscriber Identity Toolkit software layer to manage and access the multiple eSIMs stored thereon. Various embodiments of the present invention have a permanently assembled eUICC component that can not be removed from the mobile device without great effort. In addition, while the eUICC still enforces a trust barrier with the mobile device, the multiple eSIMs are stored internally within the eUICC trust boundary and can be safely modified and / or manipulated within the eUICC trust boundary.

Referring now to the 2 is an exemplary embodiment of a device 200 which is useful for implementing the methods of the present invention. The exemplary device 200 includes an application processor 202 , a safe element 204 and one or more wireless interfaces and associated baseband processors 206 , Although a mobile wireless device is shown as a UMTS compliant user equipment (UE), it will be appreciated that the device 200 can assume virtually any form factor or features consistent with the invention.

As shown, the application processor includes 202 a digital signal processor, microprocessor, field programmable gate array or a plurality of processing components mounted on one or more substrates. The processing subsystem may also include an internal cache memory. The processing subsystem is connected to a memory subsystem having memory that may include, for example, SRAM, Flash, and SDRAM components. The memory subsystem may implement one or more DMA-type hardware to facilitate data access, as is well known in the art. The memory subsystem includes computer executable instructions executable by the processor subsystem.

The safe element 204 includes a secure processor (eg, a secure microprocessor of the type known in digital processing technology) and associated secure memory. The secure memory contains computer-executable instructions that are executable by the secure processor. Unlike the other processors of the device, the secure element is isolated from other software; In particular, the secure element is permanently or semi-permanently configured to execute a code base that is known to be secure. For some variants, the secure code base can not be modified. In other variants, the secure code base can only be modified under strict conditions (eg Connect to a trusted party, such as B. the manufacturer, etc.).

The secure element comprises a virtual or electronic unit, such as A software application, hereafter referred to as an Embedded Universal Integrated Circuit Card (eUICC). In such a variant, the eUICC is able to store and manage multiple eSIMs. The eUICC selects an eSIM based on the ICCID of the eSIM. When the eUICC selects the desired eSIM (s), the UE may initiate an authentication process to obtain wireless network services from the network operator that corresponds to the eSIM. While the foregoing selection is based on ICCID, those skilled in the art will recognize that other types of identifiers may be used for eSIM management, the ICCID being merely illustrative.

In addition, the secure element includes a logical unit useful in managing a plurality of eSIMs, hereafter referred to as the "toolkit" application. In an exemplary embodiment, the toolkit application is an Advanced Subscriber Identity Toolkit software application executed internally in the secure element. Each eSIM contains its own data, such as: Phone book contacts, associated phone settings, web page bookmarks, and service profiles for other devices that the device can communicate with and / or use. An example of data is z. Conditional switching preferences defined by the user (and / or the network operator) that are useful for determining which eSIM should be active on the device. For example, such switching preferences may be based on the time of day or the day of the week, the physical location of the device, a used phonebook contact, an available network service (eg, cellular voice or data network services), the context of use (e.g. personal), the type of communication (eg voice versus data), etc.

For purposes of clarification, as used herein, the terms "active" and "inactive" refer to the execution status of the access control client and not the current connection status (i.e., an active access control client may or may not have a connection context with the network). Therefore, it may be appreciated by those skilled in the relevant art that an access control client being executed by the secure element is "active," whereas an access control client that is not being executed is "inactive."

In one embodiment, the Advanced Subscriber Identity Toolkit logical unit provides a second interface between the eUICC and eSIM data, allowing the device to access any of the eSIM data, regardless of which eSIM is actively used. As a brief side aspect, existing SIM cards typically require the user to meet an access condition (eg, a PIN code, password, administrative code, etc.). In addition, existing devices are prohibited from maintaining more than one active SIM at a time. As a result, data stored in the SIM card is effectively only available when the SIM card is actively in use. In contrast, the exemplary Advanced Subscriber Identity Toolkit provides a second interface that has different privileges and / or permissions from the primary eSIM accesses. For example, the device may use the Advanced Subscriber Identity Toolkit to search and share phonebook contacts across multiple eSIMs with the device. In another example, the Advanced Subscriber Identity Toolkit can be used to facilitate automatic and substantially seamless switching between different eSIMs by monitoring one or more conditions and comparing the monitored conditions to user-defined preferences.

In an exemplary embodiment, the secure element 204 only by the baseband processor (s) 206 be accessed directly. In such embodiments, only the application processor has 202 indirect access to the secure element (including the toolkit application and the access control clients) through the baseband processor. However, in an alternative embodiment, both the application processor 202 as well as the baseband processor (s) 206 in direct communication with the secure element 204 , An advantage if the application processor 202 is allowed, directly with the secure element 204 There is an improved flexibility in how the application processor communicates 202 Save and retrieve data. However, it should be appreciated by those skilled in the relevant art that various aspects of the present invention are directed to (i) provide multiple layers of access control and (ii) concurrent access. Thus, in some embodiments, the application processor may directly access the toolkit application without affecting the interface of the primary access control client. For example, a user may be able to search for contact information in any eSIM without necessarily (operationally) switching to a different eSIM.

In an exemplary implementation of the present invention, the device includes multiple wireless interfaces and baseband processors 206 that are capable of connecting to multiple wireless networks. The multiple wireless interfaces may be different wireless technologies such. GSM, CDMA, UMTS, LTE / LTE-A, WiMAX, WLAN, Bluetooth, etc. by implementing the appropriate antenna and modem subsystems. It will be appreciated, however, that the multiple interfaces may be homogeneous or heterogeneous; z. For example, the device may have two CDMA interfaces, a CDMA interface and an LTE interface, a WiMAX interface and a CDMA interface, and so on.

In addition, in various embodiments, the device 200 a user interface subsystem comprising any number of well known I / O including, but not limited to: a keyboard, a touch screen (e.g., a multi-touch interface), an LCD display, backlight, speaker, and / or microphone. However, it will be appreciated that in certain applications, one or more of these components may be omitted. For example, PCMCIA card type client embodiments may not have a user interface (as they may piggyback on the host device user interface to which they are physically and / or electrically coupled).

Now back up 2 Referring, in an exemplary embodiment, the secure element comprises 204 a non-transitory computer-readable medium storing one or more computer programs. The one or more computer programs are configured to implement a first level of trust (or privileges) and / or an access log that is different than the level of trust and access log required to access the access control clients (e.g. eSIM (s)). In one variant, the first level of trust (and / or privilege level) allows software access to the software of the Advanced Subscriber Identity Toolkit and is based e.g. On asymmetric or symmetric key / challenge schemes. For example, the application processor 202 properly respond to a challenge and response scheme to verify yourself as a valid piece of software. In other variants, the access log may be based on a properly signed digital certificate or another form of third party verification (eg, the processor presents a valid certificate and thereafter accesses the software of the Advanced Subscriber Identity Toolkit). In still other variations, the eUICC may be configured to verify a hardware-specific signature, a hard-coded device, or a component identifier (eg, a processor ID, etc.). In still other variations, the Advanced Subscriber Identity Toolkit may be limited in its capabilities so that a lower level of privileges (or generic privileges) may be used during the access.

In such an exemplary variant, the Advanced Subscriber Identity Toolkit is configured with fewer restrictions and faster capabilities for certain access types (as existing eSIM accesses). In some cases, the reduced restrictions require even higher levels of administrative privileges over generic user privileges. One skilled in the relevant art will readily recognize that various types of stored information associated with an eSIM can be handled at different levels of security; for example, network-specific cryptography can be very tightly protected and controlled, whereas individual user data can be protected with a lower level of protection, while generic or universal data is not given any protection at all. While existing SIM cards provide only a single access protocol (and thus always require the highest level of security, even for trivial transactions), a second (or even a third) access protocol for the Advanced Subscriber Identity Toolkit may be appropriately adapted to the privilege levels of the associated transaction (ie trivial transactions can be done with generic privileges).

For example, consider an Advanced Subscriber Identity Toolkit that is limited to adding, deleting and / or retrieving contact information and / or manipulating a call and / or a message history. While the user information is confidential and should be protected, it is appreciated that existing security and administrative privileges managed by the user are generally sufficient to protect user information. Accordingly, access to the previous Advanced Subscriber Identity Toolkit can be protected in the same manner (eg, via a user-specified password, etc.). In some variants, the Advanced Subscriber Identity Toolkit may further include more stringent security levels, e.g. B. accounting and / or billing information. For example, an administrative privilege may be required to view billing information. In addition, in some variants, an administrative master privilege may be provided, e.g. B. for service technicians and / or other specially trained personnel.

In yet another embodiment, the Advanced Subscriber Identity Toolkit is configured to provide access to a common set of data through both eSIMs and / or to provide free access to the eSIM record for each eSIM. In one implementation, the eUICC is configured with a first storage section for network data and eSIM data and a second storage section for user data. In this way, each eSIM has access to the shared memory section while still preserving its own individual memory. In other implementations, the eUICC is configured so that each eSIM has a different memory space. For each implementation, the Advanced Subscriber Identity Toolkit can be used to manage access to user data.

The 3 FIG. 12 illustrates a logical block diagram of an exemplary embodiment of an embedded Universal Integrated Circuit Card (UICC). FIG. As shown, the eUICC includes 300 a first interface for eSIM access over an existing common operating system 302 (which allows SIM for both user data access and non-user data access), and a second interface that communicates with the Advanced Subscriber Identity Toolkit 304 is. Every eSIM 308 has both accessible data for the toolkit 310 (eg, custom data, applications, etc.) and data not accessible to the toolkit 312 (eg cryptographic information, protected software, etc.). The Advanced Subscriber Identity Toolkit is configured to freely access the section of each eSIM accessible by the toolkit. In addition, the Advanced Subscriber Identity Toolkit can access an internal (or external) shared cache 306 for caching data, etc.

In some embodiments, the Advanced Subscriber Identity Toolkit 304 additionally allow a first eSIM to communicate with and / or transfer data to a second eSIM. For example, a first eSIM 308 a request for the user data 310 a second eSIM. In general, it is assumed that the user of the device owns the first and second eSIMs, therefore the Advanced Subscriber Identity Toolkit can grant the request without verification. However, with some variations, the Advanced Subscriber Identity Toolkit may additionally verify that the first eSIM has appropriate privileges to access the second eSIM. Such variants may be useful when sharing a device between multiple owners, etc.

As shown, the first interface for the common operating system 302 and the second interface for the Advanced Subscriber Identity Toolkit 304 logically different, but it is appreciated that the first and second interfaces can be implemented via either a single physical interface or different physical interfaces. In some embodiments, the first and second interfaces may be to the baseband processor 206 be coupled. In other embodiments, the first interface is the baseband processor 206 coupled and the second interface is to the application processor 202 coupled.

method

Referring now to 4 An embodiment of a generalized method for managing data in a secure element will now be described. In one implementation of the present invention, one or more access control clients are capable of storing and retrieving data associated with only that access control client. The toolkit application, which resides in the secure element, provides an additional software management layer across the multiple access control clients. The toolkit application has z. A first privilege level and the one or more access control clients have a second level of privilege. In one variant, data may be accessed at either the first or second privilege level.

At step 402 of the procedure 400 The secure element determines whether access is directed to a toolkit application or to one or more access control clients. If access is directed to an access control client (eg, an eSIM), then the secure element accesses the access control client via e.g. ISO 7816, ISO 14443, USB, etc. On the other hand, if access is directed to the toolkit application, then the process goes to step 404 further.

In one embodiment, the secure element has a single interface logically divided into (i) the toolkit application and (ii) the access control client applications. For example, SIM card interfaces typically include a clock, a reset, and a single input / output (IO). The IO line is clocked to read and write (and can be interpreted as data, addresses and / or commands). The toolkit application may be provided with a series of specialized instructions, a different memory address space, an operating mode switch, etc. For example, a secure item may have a single common interface that accepts both SIM card access and toolkit application accesses. In other example configurations, the secure element becomes physically or logically switched between SIM card access and toolkit application accesses (eg, by writing to a selection register, setting a mode switch, etc.).

In other embodiments, the secure element is provided with a different physical interface for each of the toolkit applications and the access control client applications (i.e., two interfaces). For example, as previously indicated, a SIM card interface may include a clock, a reset, and a single input / output (IO), whereas a separate address and data bus is used for toolkit access. It will also be appreciated that the two or more interfaces may share one or more common features (eg, dividing a clock and resetting, but using separate data / address busses).

In one variant, the requester is a user. For example, a user may request access to phonebook contacts associated with one (or a subset) of the one or more access control clients. In general, it is appreciated that a user will make such requests via a graphical user interface (GUI) that is executed by the application processor; however, other forms of interfaces are possible in accordance with the invention. For example, the device may have an exposed button or other physical device to initiate certain operations (eg, SIM lock, SIM exchange, etc.).

In another variant, the requestor may be a software application executing on a processor of the device. For example, if eSIM data is used to facilitate automatic switching between multiple eSIMs, a baseband processor and / or modem of the host wireless device (eg, smartphone) may request stored data switching criteria for each eSIM to automatically determine to assist which particular eSIM should be active on the device. In other examples, eSIM data may be requested by an application processor to assist in personal contact information management, etc.

In yet another variation, the requestor may be software executed internally by the eSIM itself or another eSIM. For example, a first eSIM may request a synchronization of personal contact information with a second eSIM. In yet other examples, a first eSIM may automatically configure itself in accordance with device settings associated with a second eSIM, such as: For example, an initial addition of the first eSIM to a UICC.

Those skilled in the relevant art will recognize that software spans a wide range of functionality, capabilities, and / or privileges. Known examples of software include, without limitation: firmware, low level device drivers, operating system drivers (OS), native device applications, third party software applications, networked applications, and virtual machines. Accordingly, in some embodiments of the present invention, the toolkit application may further highlight different software capabilities based on the type of requestor's software. For example, a device driver at a low level may be given different capabilities and functions than, e.g. B. a networked application.

As a brief aside, known examples of data include, without limitation, conditional operating criteria for access control clients (e.g., automatic SIM switch settings, etc.), web page bookmarks, account password lists, call and / or message history, user or financial account information , Device profile settings, software applications, etc.

Known examples of supported data access include, but are not limited to: retrieving data, storing data, modifying data (eg, overwriting or replacing), executing instructions, determining data validity (eg, performing a cyclic redundancy check (CRC), one-way cryptographic hash, or other integrity check, feature allowance / lock, etc. It is also appreciated that certain types of access may be complex and / or require the toolkit application to perform multiple internal transactions. In fact, an outstanding advantage of the example toolkit application disclosed herein is that complex transactions can be performed internally on the secure element. Existing SIM card access is performed via ISO 7816 signaling, which is much slower than the secure element's own internal access. For example, a simple read request based on the ICC ISO 7816 protocol is negotiated at a negotiated speed and can reach a maximum of several hundred kbps (kilobits per second).

At step 404 the request to access data is optionally granted for appropriate permissions, privileges and / or behavior by the toolkit. Application verified. More generally, the toolkit application only performs accesses according to the level of privilege granted by the requester; This restriction ensures that the trusted boundary of the secure element and the access control clients can not be circumvented by a clumsy or malicious use of the toolkit application. In one embodiment, the toolkit application accesses only a subset of the entire inventory of the secure element. In one variant, the subset is limited to the data that matches the privilege of the requestor. In other variants, the toolkit application itself has a maximum privilege level. For example, the toolkit application may only be able to modify and access custom data.

For example, a user may request a union of a first phone book associated with a first eSIM and a second phone book associated with a second eSIM. The toolkit application may additionally request (or encourage the user) an appropriate access PIN for one or both of the eSIMs. In other examples, the user may request access to accounting information associated with an eSIM. Responsively, the toolkit application may ask the user for a password (or PIN) before providing credit card information. In yet another example, a third-party application may request eSIM user data to allow certain functionalities (eg, in-app payments, user history statistics, etc.), the toolkit application may verify that the third-party application has been granted permission to access the user's personal information before the requested data is provided.

If the toolkit application determines that there is insufficient permission to access data, then the request for access is denied (step 406 ). In some variants, an error message may be provided to the requesting entity (eg, user, software, network entity, etc.). Otherwise, if the toolkit application determines that sufficient permission exists, the request for access is granted (step 408 ).

In addition, those skilled in the relevant art will recognize that the sensitive nature of access control client content may require additional layers of security to prevent malicious attacks. For example, various embodiments of the present invention may be configured to additionally include input validations (ie, requests are well formed and meet expected inputs), authentication / authorization, integrity checking, session management (eg, a session does not remain open or access content incorrectly , etc.), exception management (ie error conditions are handled appropriately), and / or auditing / logging.

In another example, a request may be authorized according to a certificate. For example, the requester software may need to present a certificate signed by a trusted third party, indicating that the requester software is authorized for the requested access. An example of such a certificate includes a signature (a trusted third party) that has been hashed with software identification and / or device identification. In another such example, the request is verified according to the privilege level of the requestor software. For example, consider a system where the operating system has a first privilege level, third party software has a second privilege level, and the communication software stack has another privilege level. Additionally, in some variations, the user may be able to configure one or more privilege levels (eg, grant more access to certain third party applications or withdraw privileges therefrom).

In still other cases, the application toolkit may verify that the requester software is operating in accordance with acceptable behavior. Common checks include, without limitation, verifying an input for format and length match, session time-out functions, appropriate memory operation (eg, preventing runaway pointers, etc.), etc.

At step 408 of the procedure 400 The toolkit application accesses the requested access control client data. In one embodiment, the toolkit application directly accesses the storage space of the appropriate access control client. For example, a memory mapped file structure is typically arranged according to predefined partitions. In such a variant, the partitions are divided into: (i) user-defined data (UDD), and (ii) non-user data (eg, cryptographic data, software, firmware, etc.). To access, the toolkit determines the appropriate memory address from a previously cached TOC structure or by stepping through the TOC structure until the location is found. In alternative embodiments, the toolkit application accesses the access control client via a set of access control client-specific instructions. File structures from the SIM Type are usually obfuscated to prevent direct access to stored data. Therefore, in some embodiments, the toolkit application needs to access the file structure using the native instruction set of the SIM device. While such indirect access may require more time than direct access methods, the toolkit interface advantageously does not require many of the log backups that would otherwise have to be performed using prior art techniques.

In some embodiments, the toolkit application accesses a shared memory space. Shared storage spaces may be pre-cached ahead of time with data or may be occupied on a basis as needed or as used. In general, cache memory is smaller and can be accessed faster than traditional memory structures, but it must be optimized to reduce cache "misses" (if the cache has useful data) and maximize cache "hits" ( if the cache has no useful data). For these purposes, caches implement different replacement policies; specifically, in the event of a cache miss, the cache may replace one of its existing entries with the retrieved valid data. Exchange strategies determine which existing cache entry will be least likely to be used in the future. In one variant, the cache exchanges entries according to a least recently used (LRU) paradigm, i. H. in the case of a cache miss, the cache exchanges the least recently accessed entry with the data that is stored, e.g. B. have been retried by the access control client.

At step 410 the result of the access is returned to the requestor. In some variants, the toolkit application may additionally log in accesses, update the cache, and / or provide login information to the access control client.

One skilled in the relevant art, in light of the present disclosure, will appreciate that various aspects of the present invention provide access to data via an internally controlled toolkit application that is securely executed within the secure element (and that can be inherently trusted).

Example phone book merge

5 illustrates a particular implementation of a method 500 to merge custom contact information from multiple Electronic Subscriber Identity Modules (eSIMs). Consider the scenario in which an eSIM A has a directory with 200 entries and an eSIM B has a directory with 300 entries and the eSIM A and the eSIM B 100 have overlapping entries.

At step 502 a user of a smartphone (such as the example iPhone ^™ manufactured by the Applicant) identifies two (2) eSIMs (eSIM A, eSIM B) and issues a request to merge the contact information of the two eSIMs, via a graphical user interface (GUI) executed by an application processor. In this example, the request is for an Advanced Subscriber Identity Toolkit application that runs from the secure element of the embedded Universal Integrated Circuit Card (eUICC).

At step 504 The Advanced Subscriber Identity Toolkit verifies that the requesting user has the appropriate privileges to merge the contact information. The verification of the privilege can z. Based on a PIN (or PINs) provided by the user, a password, trusted credential provided by a third-party authenticator, etc. It will be appreciated, however, that such user privilege verification may be unnecessary and in certain cases, if desired, can be skipped.

At step 506 The Advanced Subscriber Identity Toolkit retrieves the 200 entries from the eSIM A and the 300 entries from the eSIM B and performs an internal merge of the entries. It is worthy to note that prior art dual-SIM devices must necessarily authenticate to the first SIM card in order to read out the first set of entries, and then authenticate to the second SIM card, to the second To read set of entries. Even worse, prior art solutions would require that the previous operations be performed entirely through the ISO 7816 card interface, which, as previously noted, is significantly slower than the internal memory access enabled by the toolkit application.

Referring to 5 gives at step 508 the Advanced Subscriber Identity Toolkit returns the merged list of 400 entries stored in memory (eg, by the application processor). The user is informed as soon as the merger is completed.

Example contact search

6 illustrates a particular implementation of a method 600 to search for Contact information within one or more Electronic Subscriber Identity Modules (eSIMs).

At step 602 a user of a smartphone requests contact information for "John Doe". In this example, the user has not provided a target eSIM, but it is appreciated that if the user provided a target eSIM, the search can be significantly restricted.

If necessary verified at step 604 the Advanced Subscriber Identity Toolkit that the requesting user (or requesting application) has the appropriate privileges to locate the specified contact. For some variants, the Advanced Subscriber Identity Toolkit can identify the subset of eSIMs that is searchable based on the permissions of the requesting user (or application).

At step 606 The Advanced Subscriber Identity Toolkit searches the eSIMs for matching entries. As a brief aside, while existing SIM cards permit single entry accesses, in this particular scenario, prior art software would need to read the entire set of contacts to perform a search in the application processor. In particular, an index for a particular entry is unknown, existing software must read the entire set of entries from the UICC and perform a search among the entries that have been read out.

Referring back to 6 gives at step 608 The Advanced Subscriber Identity Toolkit returns the localized contact information results to the requesting user or application.

Example of a switching operation

7 illustrates a particular implementation of the method of 700 to facilitate automatic switching between Electronic Subscriber Identity Modules (eSIMs) based on a custom conditional trigger.

At step 702 of the procedure 700 A user of a smartphone defines a conditional trigger to automatically switch between eSIMs at a particular time of the day according to e.g. A use or other context. For example, a user may choose to release a first eSIM A between 7 o'clock in the morning and 5 o'clock in the evening (eg, a work account), and a second eSIM B between 5 o'clock in the evening and 7 o'clock in the morning (eg, a personal eSIM) account). The conditional toggle trigger is stored as user preference data in each respective eSIM.

At step 704 The Advanced Subscriber Identity Toolkit checks the validity of the user preference data of the conditional triggers. For example, the Advanced Subscriber Identity Toolkit can ensure that one and only one eSIM is defined for all times (ie, there are no overlaps). If the conditional triggers are valid, the Advanced Subscriber Identity Toolkit configures its triggering capability and appropriately configures each of the eSIMs (ie, to ensure that the eSIMs are enabled at their appropriate usage time, or that the switchover is not in the middle of an operational transaction, such as a call or download).

One skilled in the relevant art will recognize that prior art SIM cards do not have the previous capabilities. In addition, prior art dual-SIM devices can not cooperate in this manner because both SIM cards are different logical entities that are unable to cooperate with each other or to dictate or influence the operation of others.

At step 706 The Advanced Subscriber Identity Toolkit monitors the trigger condition (for example, a time, an event, etc.). For example, if the time of day (according to an internal clock reference or external network signaling) meets the 5 o'clock evening condition, the Advanced Subscriber Identity Toolkit switches from the first eSIM A to the second eSIM B, similarly if the 7 o'clock evening meets the condition is, the Advanced Subscriber Identity Toolkit switches from the second eSIM B to the first eSIM A.

In some variants, the eUICC (or the Advanced Subscriber Identity Toolkit) issues a "refresh" instruction to the baseband processor; In response, the baseband updates the file structure of the new eSIM and performs AKA procedures. In some cases, any such action that is invoked during a running operational condition, such as a. As a call, suspended or postponed until the termination of this condition.

It will also be welcomed that accesses to the "telephone book" of the eSIM of the example of 5 herein as a trigger condition for a context switch (and hence the eSIM). For example, a user's phonebook application running on the application processor may have marked or tagged certain contacts as "personal" and others as "professional." All professional contacts of the user can be arranged on a professional eSIM and all personal contacts on a personal eSIM; accordingly, a user's selection of a contact may cause the toolkit to select a particular eSIM or "identity" if it is not already in use.

It will be appreciated that while certain aspects of the invention have been described in terms of a specific sequence of steps of a method, these descriptions are only illustrative of the broader methods of the invention and may be modified as required by the particular application. Certain steps may become unnecessary under certain circumstances or optional. In addition, certain steps or functionalities may be added to the disclosed embodiments, or the order of performing two or more steps may be exchanged. All such variants are considered to be encompassed by the invention disclosed and claimed herein.

While the above detailed description has shown, described and emphasized novel features of the invention as applied in various embodiments, it will be understood that various omissions, substitutions and changes in the shape and details of the apparatus or illustrated method may be made by those skilled in the art can be made without departing from the invention. The foregoing description is the best mode currently contemplated for carrying out the invention. This description is in no way intended to be limiting, but should be taken as an illustration of the general principles of the invention. The scope of the invention should be determined with reference to the claims.

Claims (21)

A mobile device comprising: wireless circuitry adapted to communicate with at least one wireless network; a secure element configured to store a plurality of access control clients, wherein the plurality of access control clients comprise at least one active access control client and one inactive access control client; Logic configured to issue to the secure element a request to access a data component contained in the inactive access control client without requiring that the inactive access control client be activated; and Logic configured to receive the data component from the secure element when the secure element verifies that the request is valid. Mobile device according to claim 1, further comprising: Logic configured to transfer at least a portion of the data components to at least one access control client of the plurality of access control clients, wherein the at least one access control client does not comprise the inactive access control client. The mobile device of claim 2, wherein the at least one access control client comprises the active access control client. Mobile device according to one of claims 1 to 3, wherein the request identifies a requestor, which generates the request. Mobile device according to claim 4, wherein the requester comprises a user. Mobile device according to claim 4, wherein the requestor comprises a software application. Mobile device according to claim 6, wherein the software application resides on the secure element. The mobile device of claim 4, wherein the requestor comprises a software process resident on the active access control client. A method of managing a plurality of access control clients stored in a secure element, the method comprising: Receiving from a requestor a request to access a data component contained in a particular access control client of the plurality of access control clients; Verifying the request; Searching the plurality of access control clients for the particular access control client; Obtaining at least a portion of the data component from the particular access control client; and Returning at least a portion of the data component to the requester. The method of claim 9, wherein verifying the request comprises authenticating the requester. The method of claim 10, wherein verifying the request further comprises analyzing a privilege level associated with the requester. The method of claim 11, wherein the privilege level associated with the requester is predetermined by an administrative entity. A method according to any one of claims 9 to 12, wherein: the data component comprises contact information for a plurality of individuals; the requirement specifies a particular individual of the plurality of individuals; and the at least one portion of the data component comprises contact information for the particular individual. The method of claim 9, wherein the at least a portion of the data component comprises device configuration information for a mobile device in which the secure element is included, and wherein the method further comprises: Configure an operating state of the mobile device based on the device configuration information. A secure element configured to manage a plurality of access control clients, comprising: Means for receiving, from a requester, a request to access a data component contained in a particular access control client of the plurality of access control clients; Means for verifying the request; Means for searching the particular access control client for the data component stored therein; and Means for returning the data component to the requestor. The secure element of claim 15, wherein the requester is a user and verifying the request comprises verifying a personal identification number (PIN) or password provided by the user. The secure element of claim 15, wherein the requestor is a software application and verifying the request comprises analyzing a privilege level that is property of the software application. The secure element of claim 15, further comprising means for authenticating to a network using at least one access control client of the plurality of access control clients. A mobile device comprising: wireless circuitry adapted to communicate with a wireless network; a processor; a memory device in data communication with the processor, the memory device storing computer-executable instructions configured to, when executed by the processor, cause the processor to: to a secure element included in the mobile device and configured to store a plurality of access control clients, to transmit a request to access a data component contained in a particular access control client of the plurality of access control clients, wherein the request includes specifies a specific privilege level that allows access to the data component; and the secure element, where the secure element is configured to: to verify the requirement; to access the data component of the particular access control client; and to return the data component to the processor. A method of accessing a data component contained in an access control client stored in a secure element of a user device, comprising: at a processor included in the user device, transmitting a request to the secure element to access the data component, the secure element storing a plurality of access control clients comprising the access control client, and wherein the access control client is inactive; at the secure element, verifying the request and, if the request is valid, accessing the data components and providing the data component to the processor; at the processor, receiving the data component from the secure element; and at the processor, modifying the operating state of the user device based on the received data component. A secure element configured to store a plurality of access control clients, wherein each access control client of the plurality of access control clients includes a data component, the secure element comprising: a secure processor; and a secure storage device in data communication with the secure processor, the secure storage device being computer-executable Store instructions configured to, when executed by the secure processor, cause the secure processor to: receive from a requestor a request to access the data component of an access control client of the plurality of access control clients, the access control client being inactive, and the request comprises privilege level information associated with the requester; to verify the request based on the privilege level information; access the data component of the inactive access control client; and return the data component to the requestor.

Images