Classifications

• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04W—WIRELESS COMMUNICATION NETWORKS
  • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
  • H04W12/08—Access security
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04W—WIRELESS COMMUNICATION NETWORKS
  • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
  • H04W12/08—Access security
  • H04W12/086—Access security using security domains
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04W—WIRELESS COMMUNICATION NETWORKS
  • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
  • H04W12/40—Security arrangements using identity modules
  • H04W12/45—Security arrangements using identity modules using multiple identity modules
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04W—WIRELESS COMMUNICATION NETWORKS
  • H04W8/00—Network data management
  • H04W8/18—Processing of user or subscriber data, e.g. subscribed services, user preferences or user profiles; Transfer of user or subscriber data
  • H04W8/183—Processing at user equipment or user record carrier

Definitions

• the present invention relates generally to the field of communications systems, and more particularly in one exemplary aspect, to facilitating the sharing of data between multiple user access clients of one or more mobile devices.
• Access control is required for secure communication in most prior art wireless radio communication systems.
• one simple access control scheme might comprise: (i) verifying the identity of a communicating party, and (ii) granting a level of access commensurate with the verified identity.
• access control is governed by an access control client, referred to as a Universal Subscriber Identity Module (USIM) executing on a physical Universal Integrated Circuit Card (UICC) (also referred to as a "SIM card”).
• UICC Universal Integrated Circuit Card
• SIM card also referred to as a "SIM card”
• access control client refers generally to a logical entity, either embodied within hardware or software or combinations thereof, suited for controlling access of a first device to a network.
• access control clients include the aforementioned USIM, CDMA Subscriber Identification Modules (CSIM), IP Multimedia Services Identity Module (ISIM), Subscriber Identity Modules (SIM), Removable User Identity Modules (RUIM), etc.
• the UICC enforces a trusted boundary for one or more USIM (or more generally "SIM") access control clients.
• the UICC is manufactured and "hardcoded" with a SIM, i.e., once programmed, the UICC cannot be reprogrammed. If a user wants to authenticate to a cellular network using a different SIM, the user must physically exchange the SIM card in the device with a different SIM card.
• some devices have been designed to house two SIM cards at the same time, known as Dual-SIM phones.
• Dual-SIM phones do not address the fundamental physical limitations of SIM card devices. For example, information stored within one SIM card cannot be easily consolidated with information stored within another SIM card.
• Dual-SIM devices cannot access the contents of both SIM cards simultaneously. Lastly, accessing a SIM card requires a perceptible and non-trivial amount of time for the user; switching between SIM cards to transfer information is undesirable and reduces user experience, and this limitation is present in both traditional and Dual-SIM devices.
• the present invention satisfies the aforementioned needs by providing, inter alia, improved apparatus and methods for sharing of data between multiple user access clients of one or more mobile devices.
• a secure element configured to store one or more access control clients, each of the one or more access control clients containing data
• the secure element includes a secure processor; and a secure storage device in data communication with the secure processor.
• the storage device includes computer- executable instructions that are configured to, when executed by the secure processor: receive a request to access a first data of an inactive first access control client; verify the request; access the first data of the inactive first access control client; and return the first data.
• each of the one or more access control clients includes computer-executable instructions that are configured to, when executed by the secure processor: receive a request to authenticate an active second access control client from a network entity; authenticate the request; and when the request is authentic, respond to the network entity.
• requests to access data and network-originated requests are at distinct privilege levels.
• the request identifies a requestor.
• the requestor may be a user.
• the requestor may be a software application.
• the software application is resident on the secure element.
• the requestor includes a software process on a second of the one or more access control clients on the secure element.
• a method for processing data within a secure element configured to store one or more access control clients each containing data.
• the method includes: receiving a request to access a first data; verifying the request; searching a plurality of access control clients for the first data; and when the first data is found, returning the first data.
• verifying the request includes identifying the requestor. In one such example, verifying the request further includes determining a privilege associated with the requestor. In another example, the determined privilege associated with the requestor is pre-determined by an administrative entity.
• accessing the first data includes accessing a plurality of contact information to identify a single contact.
• the accessing the first data includes accessing one or more device configurations, the accessing enabling configuration of a device according to at least one of the one or more configurations.
• a secure element configured to store one or more access control clients, each of the one or more access control clients containing data.
• the secure element includes: means for receiving a request to access a first data; means for verifying the request; means for searching the one or more access control clients for the first data; and means for returning the first data.
• the means for verifying the request comprises means for verifying a personal identification number (PIN) or password supplied by a user.
• PIN personal identification number
• the means for verifying the request comprises means for determining a software privilege level of a software application.
• the secure element includes means for receiving a network request to authenticate the access control client.
• a mobile device in one embodiment, includes: a secure element, the secure element configured to store one or more access control clients, each of the one or more access control clients containing data; one or more wireless communications circuitry adapted to communicate with a communications network; a first processor; a storage device in data communication with the first processor, the storage device comprising computer- executable instructions that are configured to, when executed by the first processor: transmit a request to access a first data of a first access control client according to a first privilege, the first privilege limited to toolkit accessible data; the request configured to cause the secure element to: verify the request; access the first data of the first access control client; and return the first data to the first processor.
• a method for accessing data within a secure element of a user device includes: transmitting a request to access a first data stored on the secure element of the user device; responsive to receiving the request, the secure element verifying the request; when the request is valid, locating the first data on one of a plurality of access control clients; and receiving the first data from the secure element.
• a mobile device in a sixth aspect of the present invention, includes: a secure element, the secure element configured to store one or more access control clients, each of the one or more access control clients containing data; one or more wireless communications circuitry adapted to communicate with a communications network; logic configured to request access to a first data of a first of one or more inactive access control clients stored on the secure element; where the secure element is configured to verify the request and when the request is valid, provide the first data of the first access control client; and logic configured to receive the first data from the secure element.
• FIG. 1 graphically illustrates one exemplary Authentication and Key Agreement (AKA) procedure using a prior art USIM.
• AKA Authentication and Key Agreement
• FIG. 2 is a block diagram of an exemplary embodiment of an apparatus useful for implementing the methods of the present invention.
• 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.
• FIG. 4 is a logical flow diagram of one embodiment of a generalized method for the management of data within a secure element, according to various aspects of the present invention.
• UICC Universal Integrated Circuit Card
• FIG. 5 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.
• eSIMs electronic Subscriber Identity Modules
• FIG. 6 is a logical flow diagram illustrating one embodiment of a method for searching for contact information within multiple electronic Subscriber Identity Modules (eSIMs) according to the present invention.
• eSIMs electronic Subscriber Identity Modules
• FIG. 7 is a logical flow diagram illustrating one embodiment of a method for facilitating automatic switch-over between electronic Subscriber Identity Modules (eSIMs) based on a user-defined conditional trigger, according to the present invention.
• eSIMs electronic Subscriber Identity Modules
• an embedded Universal Integrated Circuit Card e.g., an Advanced Subscriber Identity Toolkit
• UICC Universal Integrated Circuit Card
• UICC User-defined Data
• the Advanced Subscriber Identity Toolkit provides a secondary privileged interface that enables faster access to data stored within the eSIM, without compromising the integrity of eSIM security.
• a logical entity such as the aforementioned Advanced Subscriber Identity Toolkit is configured to monitor operational or other conditions of a device, and compare them against eSIM usage preferences that have been specified by a user (or, e.g., a network operator, etc.).
• the exemplary implementation of the Advanced Subscriber Identity Toolkit can further automatically switch the active eSIM, according to the desired preferences.
• SIMs Subscriber Identity Modules
• subscriber identity module e.g., SIM, USIM, CSIM, eSIM, etc.
• subscriber identity module e.g., SIM, USIM, CSIM, eSIM, etc.
• identity module e.g., SIM, USIM, CSIM, eSIM, etc.
• SIM Subscriber Identity Module
• a user equipment includes a mobile device and a Universal Subscriber Identity Module (USIM).
• the USIM is a logical software entity that is stored and executed from a physical Universal Integrated Circuit Card (UICC).
• UICC Universal Integrated Circuit Card
• a variety of information is stored in the USIM such as subscriber information, as well as the keys and algorithms used for authentication with the network operator in order to obtain wireless network services.
• the keys and/or cryptographic algorithms are stored within the operating system of the UICC.
• the USIM software is based on the Java CardTM programming language. Java Card is a subset of the JavaTM programming language that has been modified for embedded "card" type devices (such as the aforementioned UICC).
• UICCs are programmed with a USIM prior to subscriber distribution; the pre-programming or "personalization" is specific to each network operator.
• the USIM is associated with an International Mobile Subscriber Identify (IMSI), a unique Integrated Circuit Card Identifier (ICCID) and a specific authentication key (K).
• IMSI International Mobile Subscriber Identify
• ICCID unique Integrated Circuit Card Identifier
• K specific authentication key
• the network operator stores the association in a registry contained within the network's Authentication Center (AuC).
• AuC Authentication Center
• FIG. 1 one exemplary Authentication and Key Agreement (AKA) procedure using the aforementioned prior art USIM is illustrated in detail.
• AKA Authentication and Key Agreement
• the UE passes 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 AuC's registry and obtains the appropriate key K.
• the HN generates a random number (RAND) and signs it with key K using an algorithm to create the expected response (XRES).
• the HN further generates a Cipher Key (CK) and an Integrity Key (IK) for use in cipher and integrity protection as well as an Authentication Token (AUTN) using 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 passes the RAND and AUTN to the UE.
• the USIM verifies if the received AUTN is valid. If so, the UE uses the received RAND to compute its own response (RES) using the stored key K and the same algorithm that generated the XRES. The UE passes the RES back to the SN. The SN compares the XRES to the received RES and if they match, the SN authorizes the UE to use the operator's wireless network services.
• RES own response
• the UICC is generally programmed with other applications that provide enhanced functionality to the UICC.
• applications are a phonebook, or a USIM Application Toolkit (USAT).
• USAT is typically used as a Value Added Service technology that extends the communication protocol between the UICC and the device.
• Asymmetric key schemes use different keys to encrypt and decrypt messages, and thus the encrypter and decrypter do not share the same key.
• Symmetric key schemes utilize the same key (or trivially transformed keys) for both encryption and decryption.
• the Rivest, Shamir and Adleman (RSA) algorithm is one type of public/private key pair cryptography that is commonly used within the related arts, but it will be recognized that the present invention is in no way limited to the RSA algorithm.
• Public/private cryptography schemes can be used to encrypt a message, and/or generate signatures. Specifically, a message can be encrypted with a private key, and decrypted with the public key, thereby assuring that the message has not been altered in transit. Similarly, a signature generated with the private key can be verified with the public key, assuring that the entity generating the signature is legitimate. In both uses, the private key is kept hidden, and the public key is freely distributed.
• SIM cards can be freely moved between mobile devices but the SIM itself is hardcoded within the UICC. While SIM cards can be pre-programmed with multiple SIMs (e.g., a USIM and a CSIM, etc.), the existing deployments generally only contain a single SIM. According to existing SIM trust architectures, the mobile device is not a trusted entity; thus, the SIM card must determine if the mobile device has been compromised before granting access. In fact, the SIM is only configured to establish trusted communications with a Home Network (HN) or Serving Network (SN) that has access to appropriate cryptographic secrets.
• HN Home Network
• SN Serving Network
• a secure element (UICC, eUICC, etc.), is configured to store multiple SIM elements, referred hereafter as Electronic Subscriber Identity Modules (eSIM).
• eSIM Electronic Subscriber Identity Modules
• Each eSIM is a software emulation of a typical USIM, and contains analogous programming and user data associated therewith.
• an eSIM may include additional software and/or applications in addition to the USIM applications.
• an embedded UICC (eUICC) resident within 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 mounted eUICC component that cannot be removed from the mobile device without great effort. Moreover, while the eUICC still enforces a trust boundary with the mobile device, the multiple eSIMs are stored internally within the eUICC trust boundary and can be securely modified and/or manipulated from within the eUICC trust boundary.
• the exemplary apparatus 200 includes an applications processor 202, a secure element 204, and one or more wireless interfaces and associated baseband processors 206. While shown as UMTS-compliant user equipment (UE) mobile wireless device, it will be appreciated that the apparatus 200 may take on literally any form factor or characteristics consistent with the invention.
• UE user equipment
• the application processor 202 includes a digital signal processor, microprocessor, field-programmable gate array, or 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 comprising memory that may, for example, comprise SRAM, flash and SDRAM components.
• the memory subsystem may implement one or a more of DMA type hardware, so as to facilitate data accesses as is well known in the art.
• the memory subsystem contains computer-executable instructions that are executable by the processor subsystem.
• the secure element 204 includes a secure processor (e.g., secure microprocessor of the type known in the digital processing arts) and associated secure storage.
• the secure storage contains computer-executable instructions that are executable by the secure processor.
• 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.
• the secure code base cannot be modified.
• the secure code base can only be modified under strict conditions (e.g., connection to a trusted party such as the manufacturer, etc.).
• the secure element includes a virtual or electronic entity such as, e.g., a software application, hereafter referred to as an Embedded Universal Integrated Circuit Card (eUICC).
• eUICC is capable of storing and managing multiple eSIMs.
• the eUICC selects an eSIM based upon the eSIM's ICCID. Once the eUICC selects the desired eSIM(s), the UE can initiate an authentication procedure to obtain wireless network services from the eSIM's corresponding network operator. While the foregoing selection is based on ICCID, those of ordinary skill will recognize that other types of identifiers may be used for eSIM management, the ICCID being purely illustrative.
• the secure element includes a logical entity useful in managing a multitude of eSIMs, hereafter referred to as the "toolkit" application.
• the toolkit application is an Advanced Subscriber Identity Toolkit software application executed internally within the secure element.
• Each eSIM contains its own data, such as, e.g. phonebook contacts, associated phone settings, web page bookmarks, and service profiles for other devices that the apparatus may communicate with and/or use.
• data is, e.g., conditional switch-over preferences that are defined by the user (and/or network operator) and are useful for determining which eSIM should be active on the device.
• switch-over preferences may be based on time of day or day of the week, physical location of the device, phonebook contact being used, an available wireless network service (e.g. voice or data cellular network service), context of use (e.g., business, personal), type of communication (e.g., voice versus data), etc.
• an available wireless network service e.g. voice or data cellular network service
• context of use e.g., business, personal
• type of communication e.g., voice versus data
• active and inactive refer to the execution status of the access control client, not the current connection status (i.e., an active access control client may or may not have a connection context to the network).
• an access control client that is being executed by the secure element is “active,” whereas an access control client that is not executed is “inactive.”
• the Advanced Subscriber Identity Toolkit logical entity provides a secondary interface between the eUICC and the eSIM's data, allowing the apparatus to access any of the eSIM's data regardless of which eSIM is actively being used.
• existing SIM cards typically require the user to satisfy an access condition (e.g., a PIN code, password, administrative code, etc.).
• existing devices are prohibited from maintaining more than one active SIM at a time. Consequently, data that has been stored within a SIM card is effectively only available when the SIM card is in active use.
• the exemplary Advanced Subscriber Identity Toolkit provides a secondary interface that has different privileges and/or permissions from the primary eSIM accesses.
• the apparatus can use the Advanced Subscriber Identity Toolkit to query and share phonebook contacts across multiple eSIMs with the apparatus.
• the Advanced Subscriber Identity Toolkit may be used to facilitate automatic and substantially seamless switch-over between different eSIMs by monitoring one or more conditions and comparing the monitored conditions against user-defined switchover preferences.
• the secure element 204 is only directly accessible by the baseband processor(s) 206.
• the application processor 202 only has indirect access to the secure element (including the toolkit application and access control clients), via the baseband processor.
• both the application processor 202 and baseband processor(s) 206 are in direct communication with the secure element 204.
• a benefit of allowing the application processor 202 to communicate directly with the secure element 204 is enhanced flexibility in how the application processor 202 can store and retrieve data.
• various aspects of the present invention are directed to providing: (i) multiple layers of access control, and (ii) concurrent access.
• the application processor can directly access the toolkit application, without affecting the primary access control client interface.
• a user may be able to search for contact information in any eSIM, without necessarily (operationally) switching to a different eSIM.
• the device includes multiple wireless interfaces and baseband processors 206 adapted to connect to multiple wireless networks.
• the multiple wireless interfaces may support different radio technologies such as 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; e.g., the device may have two CDMA interfaces, a CDMA interface and an LTE interface, a WiMAX interface and a CDMA interface, and so forth.
• the apparatus 200 may comprise a user interface subsystem including any number of well-known I/O including, without limitation: a keypad, touch screen (e.g., multi-touch interface), LCD display, backlight, speaker, and/or microphone.
• a keypad e.g., multi-touch interface
• LCD display e.g., backlight, speaker, and/or microphone.
• PCMCIA card-type client embodiments may lack a user interface (as they could piggyback onto the user interface of the host device to which they are physically and/or electrically coupled).
• the secure element 204 includes a non-transitory computer readable medium that stores one or more computer programs.
• the one or more computer programs are configured to implement a first level of trust (or privileges) and/or access protocol that is different than the level of trust and access protocol required to access the access control clients (e.g., eSIM(s)).
• the first level of trust and (or privileges) enables software access to the Advanced Subscriber Identity Toolkit software, and is based on, e.g., asymmetric or symmetric key/challenge schemes.
• the application processor 202 may need to properly respond to a challenge and response scheme to verify itself as a valid software entity.
• the access protocol may be based on a properly signed digital certificate, or other form of 3rd party verification (e.g., the processor presents a valid certificate and can thereafter access the Advanced Subscriber Identity Toolkit software).
• eUICC may be configured to check a hardware-specific signature, hardcoded device or component identifier (e.g., a processor ID, etc.), etc.
• the Advanced Subscriber Identity Toolkit may be limited in capabilities, such that a lower degree of privileges (or generic privileges) can be used during access.
• the Advanced Subscriber Identity Toolkit is configured with fewer restrictions and faster capabilities (than existing eSIM accesses) for certain types of accesses. In some cases, the reduced restrictions still require higher levels of administrative privileges over generic user privileges.
• eSIM electronic Subscriber Identity Toolkit
• network-specific cryptography may be very tightly protected and controlled, whereas individual user data may be protected with lower degrees of protection, while generic or ubiquitous data is given no protection at all.
• SIM cards only provide a single access protocol (and thus always require the highest level of security, even for trivial transactions)
• a second (or even third) access protocol for the Advanced Subscriber Identity Toolkit can be matched commensurate to the privilege levels of the associated transaction (i.e., trivial transactions may be performed with generic privileges).
• Advanced Subscriber Identity Toolkit that is limited to adding, deleting, and/or retrieving contact information, and/or manipulating call and/or messaging history. While user information is confidential and should be protected, it is appreciated that existing security and administrative privileges that are managed by the user are generally sufficient for protecting user information. Accordingly, access to the foregoing Advanced Subscriber Identity Toolkit can be protected in the same manner (e.g., via a user determined password, etc.).
• the Advanced Subscriber Identity Toolkit may further include more stringent security levels, e.g., accounting and/or billing information. For example, an administrative privilege may be required to view billing information.
• a master administrative privilege may be provided, e.g., service technicians, and/or other specially trained personnel.
• the Advanced Subscriber Identity Toolkit is configured to provide access to a common set of data by both eSIMs, and/or freely access the eSIM data set for each eSIM.
• the eUICC is configured with a first section of memory for network data and eSIM data, and a second section of memory for user data. In this manner, each eSIM has access to the common section of memory while still preserving its own individual memory.
• the eUICC is configured such that each eSIM has a distinct memory space. In either implementation, the Advanced Subscriber Identity Toolkit can be used to manage access to user data.
• FIG. 3 illustrates a logical block diagram of one exemplary embodiment of an embedded Universal Integrated Circuit Card (UICC).
• the eUICC 300 includes a first interface for eSIM access via an existing Common Operating System 302 (that enables SIM procedures for both user data access, and non-user data access), and a second interface that is in communication with the Advanced Subscriber Identity Toolkit 304.
• Each eSIM 308 has both toolkit accessible data 310 (e.g., user- defined data, applications, etc.), and non-toolkit accessible data 312 (e.g., cryptographic information, protected software, etc.).
• the Advanced Subscriber Identity Toolkit is configured to freely access the toolkit accessible portion of each eSIM. Additionally, the Advanced Subscriber Identity Toolkit may have access to an internal (or external) common memory cache 306 for caching data, etc.
• the Advanced Subscriber Identity Toolkit 304 may additionally enable a first eSIM to communicate and/or transact data with a second eSIM.
• a first eSIM 308 can issue a request for the user data 310 of a second eSIM.
• the Advanced Subscriber Identity Toolkit may grant the request without verification.
• the Advanced Subscriber Identity Toolkit can additionally verify that the first eSIM has appropriate privileges for accessing the second eSIM. Such variants may be useful where a device is shared between multiple owners, etc.
• the first interface for the Common Operating System 302 and the second interface for the Advanced Subscriber Identity Toolkit 304 are logically distinct, however it is appreciated that the first and second interfaces may be implemented over either a single physical interface, or distinct physical interfaces.
• the first and second interfaces may be coupled to the baseband processor 206.
• the first interface is coupled to the baseband processor 206, and the second interface is coupled to the application processor 202.
• one or more access control clients are capable of storing and retrieving data that is uniquely associated to that access control client.
• the toolkit application residing within the secure element provides an additional software management layer over the multiple access control clients.
• the toolkit application has for example a first privilege level, and the one or more access control clients have a second privilege level.
• data can be accessed with either the first or the second privilege levels.
• the secure element determines if an access is directed to a toolkit application, or one or more access control clients. If the access is directed to an access control client (e.g., an eSIM), then the secure element provides access to the access control client via, e.g., ISO 7816, ISO 14443, USB, etc. Otherwise, if the access is directed to the toolkit application, then the method proceeds to step 404.
• an access control client e.g., an eSIM
• the secure element provides access to the access control client via, e.g., ISO 7816, ISO 14443, USB, etc. Otherwise, if the access is directed to the toolkit application, then the method proceeds to step 404.
• the secure element has a single interface that is logically divided into (i) the toolkit application, and (ii) the access control client applications.
• SIM card interfaces typically include a clock, a reset, and a single input/output (10).
• the 10 line is clocked to read and write (and can be interpreted as data, address, and/or instructions).
• the toolkit application may be provided with a series of specialized commands, a distinct memory address space, an operational mode switch, etc.
• a secure element may have a single common interface that accepts both SIM card accesses and toolkit application accesses.
• the secure element is physically or logically switched between SIM card accesses and toolkit application accesses (e.g., by writing to a selection register, setting a mode switch, etc.).
• the secure element is provided with a distinct physical interface for each of the toolkit application and the access control client applications (i.e., two interfaces).
• a SIM card interface may include a clock, a reset, and a single input/output (IO), whereas a separate address and data bus are used for toolkit access.
• IO input/output
• the two or more interfaces may share one or more common features (e.g., share a clock and reset, yet utilize separate data/address busses).
• the requestor is a user.
• a user may request access to phonebook contacts associated with any (or a subset) of the one or more access control clients.
• GUI Graphical User Interface
• the device may have an exposed button or other physical means for triggering certain operations (e.g., SIM lock, SIM swap, etc.).
• the requestor may be a software application executing on a processor of the device.
• a baseband processor and/or modem of the host radio device e.g., smart phone
• eSIM data can be requested by an application processor to assist in personal contact information management, etc.
• the requestor may be software executed internally by the eSIM itself, or another eSIM.
• a first eSIM may request synchronization of personal contact information with a second eSIM.
• a first eSIM may automatically configure itself in accordance with device settings associated with a second eSIM, such as upon initial addition of the first eSIM to a UICC.
• the toolkit application may further expose different software capabilities, based on the requestor software type. For example, a low-level device driver may be afforded different capabilities and functions than, e.g., a networked application.
• conditional operational criteria for access control clients e.g., settings for automatic SIM switching, etc.
• website bookmarks e.g., account password lists
• call and/or messaging history e.g., phone number, phone number, etc.
• Common examples of supported data accesses include, but are not limited to: retrieving data, storing data, modifying data (e.g., writing over or replacing it), executing instructions, determining data validity (e.g., performing a cyclic redundancy check (CRC), one-way cryptographic hash, or other integrity check), enabling/disabling features, etc.
• certain types of accesses may be complex and/or require the toolkit application to perform multiple internal transactions.
• one salient advantage of the exemplary toolkit application disclosed herein is that complex transactions can be performed internal to 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 via the ICC ISO 7816 protocol is based on a negotiated speed and can maximally reach up to several hundred kbps (kilobits per second).
• the request to access the data is optionally verified for appropriate permissions, privileges, and/or behavior by the toolkit application. More generally, the toolkit application only performs accesses commensurate with the level of privilege afforded to the requestor; this limitation ensures that the trust boundary of the secure element and access control clients cannot be circumvented by inadvertent or malicious use of the toolkit application. In one embodiment, the toolkit application only accesses a subset of the entire secure element's assets. In one variant, the subset is limited to the data corresponding to the requestor's privilege. In other variants, the toolkit application itself has a maximum privilege level. For example, the toolkit application may only be able to access/modify user-defined data.
• a user may request a merge of a first phonebook associated with a first eSIM and a second phonebook associated with a second eSIM; the toolkit application may additionally require (or prompt the user for) an appropriate access ⁇ for one or both of the eSIMs.
• the user may request access to billing information associated with an eSIM.
• the toolkit application may prompt the user for a password (or PIN) before providing credit card information.
• a 3rd party application may request eSIM user data to enable certain functionality (e.g., in-app payment, usage history statistics, etc.), the toolkit application may verify that the 3rd party application has been granted permission to access the user's personal information before providing the requested data.
• certain functionality e.g., in-app payment, usage history statistics, etc.
• the request for access is denied (step 406).
• an error message may be provided to the requesting entity (e.g., user, software, network entity, etc.). Otherwise, when the toolkit application determines there is sufficient permission, the request for access is granted (step 408).
• various embodiments of the present invention may be configured to additionally perform, inter alia, input validation (i.e., requests are well-formed and comply with expected inputs), authentication/authorization, integrity checks, session management (e.g., a session does not remain open or access assets improperly, etc.), exception management (i.e., error conditions are handled properly), and/or auditing/logging.
• input validation i.e., requests are well-formed and comply with expected inputs
• authentication/authorization i.e., integrity checks
• session management e.g., a session does not remain open or access assets improperly, etc.
• exception management i.e., error conditions are handled properly
• auditing/logging i.e., error conditions are handled properly.
• a request can be authorized according to a certificate.
• the requestor software may be required to present a certificate that has been signed by a trusted 3rd party, which indicates that the requestor software is authorized for the requested access.
• a certificate includes a signature (of a trusted 3rd party) that has been hashed with a software identification and/or device identification.
• the request is verified according to the requester software privilege level. For example, consider a system where the operating system has a first privilege level, 3rd party software has a second privilege level, and the communications software stack has yet another privilege level.
• the user may be additionally able to configure one or more privilege levels (e.g., to grant certain 3rd party applications more access, or revoke privileges therefrom).
• the application toolkit may verify that the requester software is operating in accordance with acceptable behavior.
• Common checks include, without limitation: verifying input for conformance to format and length, session timeout functions, proper memory operation (e.g., preventing runaway pointers, etc.), etc.
• the toolkit application accesses the requested data of the access control client.
• the toolkit application accesses the memory space of the appropriate access control client directly.
• a memory-mapped file structure is typically arranged according to predefined partitions.
• the partitions are divided into: (i) user defined data (UDD), and (ii) non-user data (e.g., cryptographic data, software, firmware, etc.).
• UDD user defined data
• non-user data e.g., cryptographic data, software, firmware, etc.
• the toolkit determines the appropriate memory address from a previously cached directory structure, or by traversing the directory structure iteratively until the memory location is found.
• the toolkit application accesses the access control client via a set of access control client- specific instructions.
• SIM type file structures are commonly obfuscated to prevent straightforward access of stored data.
• the toolkit application must access the file structure using the SIM device's native command set. While such indirect access may require more time than direct access methods, the toolkit interface advantageously does not require many of the protocol safeguards that would otherwise have to be performed utilizing prior art techniques.
• the toolkit application accesses a common memory space.
• Common memory spaces can be pre-cached ahead of time with data, or may be populated on an as-needed or as-used basis.
• cache memory is smaller and faster to access than traditional memory structures, but must be optimized to reduce cache "misses" (when the cache has useful data) and maximize cache "hits" (when the cache does not have useful data).
• cache memories implement different replacement policies; specifically, on a cache miss, the cache may replace one of its existing entries with the retrieved valid data. Replacement policies determine which existing cache entry is least likely to be used in the future.
• the cache replaces entries according to a least-recently used (LRU) paradigm, i.e., on a cache miss, the cache replaces the least recently accessed entry with the data that is retrieved from, e.g., the access control client.
• LRU least-recently used
• the result of the access is returned to the requestor.
• the toolkit application may additionally log accesses, update the cache, and/or provide log information to the access control client.
• FIG. 5 illustrates one particular implementation of a method 500 for merging user-defined contact information of multiple electronic Subscriber Identity Modules (eSIMs).
• eSIM A has a phonebook with 200 entries
• eSIM B has a phonebook with 300 entries
• eSIM A and eSIM B have 100 overlapping entries.
• a user of a smart phone 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 from an application processor.
• GUI graphical user interface
• the request is directed to an Advanced Subscriber Identity Toolkit application that is executed from the embedded Universal Integrated Circuit Card (eUICC) secure element.
• eUICC embedded Universal Integrated Circuit Card
• the Advanced Subscriber Identity Toolkit verifies that the requesting user has the appropriate privileges to merge the contact information. Verification of privilege may be based on, e.g., a user supplied ⁇ (or PINs), password, trusted credential provided by a 3rd party authenticator, etc. It will be appreciated however that such verification of the user's privilege may be unnecessary and skipped in certain cases if desired.
• the Advanced Subscriber Identity Toolkit retrieves the 200 entries from eSIM A and the 300 entries from eSIM B, and performs an internal merge of the entries. It is worth noting that prior art Dual-SIM devices would necessarily need to authenticate to the first SIM card to read out the first set of entries, and subsequently thereafter authenticate to the second SIM card to read out the second set of entries. Worse still, prior art solutions would be required to perform the foregoing operations entirely over the ISO 7816 card interface that, as previously noted, is significantly slower than the internal memory access afforded by the toolkit application.
• the Advanced Subscriber Identity Toolkit returns the merged list of 400 entries that are stored in memory (e.g., by the application processor). The user is notified once the merge is completed.
• FIG. 6 illustrates one particular implementation of a method 600 for searching for contact information within one or more electronic Subscriber Identity Modules (eSIMs).
• eSIMs electronic Subscriber Identity Modules
• a user of a smart phone requests contact information for "John Doe".
• the user has not provided a target eSIM, however it is appreciated that when the user has provided a target eSIM, the search can be significantly constrained.
• the Advanced Subscriber Identity Toolkit verifies that the requesting user (or requesting application) has the appropriate privileges to search for the indicated contact.
• the Advanced Subscriber Identity Toolkit may identify the subset of eSIMs that are searchable, based on the requesting user's (or application's) permissions.
• the Advanced Subscriber Identity Toolkit searches the eSIMs for matching entries.
• existing SIM cards allow single entry access
• prior art software would be required to read the entire set of contacts to perform a search in the application processor.
• an index is unknown for a particular entry
• existing software has to read the entire set of entries out of the UICC and perform a search among the entries that were read out.
• the Advanced Subscriber Identity Toolkit returns the located contact information results to the requesting user or application.
• FIG. 7 illustrates one particular implementation of the method of 700 for facilitating automatic switch-over between electronic Subscriber Identity Modules (eSIMs) based on a user-defined conditional trigger.
• eSIMs electronic Subscriber Identity Modules
• a user of a smart phone defines a conditional trigger to automatically switch between eSIMs at a particular time of day corresponding to, e.g., a use or other context. For example, a user may elect to enable a first eSIM A between 7:00AM to 5:00PM (e.g., a work account), and a second eSIM B between 5:00PM to 7:00AM (e.g., a personal account).
• the switch-over conditional trigger is stored as user preference data within each respective eSIM.
• the Advanced Subscriber Identity Toolkit checks the user preference data conditional triggers for validity. For example, the Advanced Subscriber Identity Toolkit may ensure that one, and only one, eSIM is defined for all times (i.e., that there are no overlaps). If the conditional triggers are valid, then the Advanced Subscriber Identity Toolkit configures its triggering capability, and configures each of the eSIMs appropriately (i.e., ensuring that the eSIMs are enabled at their appropriate time of use, or that the changeover is not performed in the middle of an operational transaction such as a call or download).
• the Advanced Subscriber Identity Toolkit may ensure that one, and only one, eSIM is defined for all times (i.e., that there are no overlaps). If the conditional triggers are valid, then the Advanced Subscriber Identity Toolkit configures its triggering capability, and configures each of the eSIMs appropriately (i.e., ensuring that the eSIMs are enabled at their appropriate time of use, or that the changeover is not performed in the middle
• SIM cards do not have the foregoing capabilities.
• prior art Dual-SIM devices also cannot collaborate in this manner, as both SIM cards are distinct logical entities that are unable to cooperate with, or dictate or influence the operation of, the other.
• the Advanced Subscriber Identity Toolkit monitors for the triggering condition (e.g., a time, an event, etc.). For example, when the time of day (according to an internal clock reference, or per external network signaling) satisfies the 5:00PM condition, the Advanced Subscriber Identity Toolkit swaps from the first eSIM A to the second eSIM B; similarly, when the 7:00PM condition is satisfied, the Advanced Subscriber Identity toolkit swaps from the second eSIM B to the first eSIM A.
• the triggering condition e.g., a time, an event, etc.
• the eUICC (or the Advanced Subscriber Identity Toolkit) issues a "refresh" instruction to the baseband processor; responsively the baseband refreshes to the file structure of the new eSIM and performs AKA procedures.
• any such action that is invoked during an ongoing operational condition, such as a call may be suspended or postponed until the completion of that condition.
• accesses to the eSIM "phonebook" of the example of FIG. 5 herein may be used as a triggering condition for a context (and hence eSIM) change.
• a user's phonebook application running on the application processor may have certain contacts marked or designated as "personal”, and others as "business". All user business contacts may be disposed on a business eSIM, and all personal contacts are on a personal eSIM; accordingly, a user selection of a contact may invoke the Toolkit to select a particular eSIM or "identity" if not already in use.

Landscapes

• Engineering & Computer Science (AREA)
• Computer Security & Cryptography (AREA)
• Computer Networks & Wireless Communication (AREA)
• Signal Processing (AREA)
• Telephone Function (AREA)
• Mobile Radio Communication Systems (AREA)
• Telephonic Communication Services (AREA)

Priority Applications (3)

Applications Claiming Priority (4)

Publications (1)

Family

ID=50278623

Family Applications (1)

Country Status (5)

Cited By (7)

Families Citing this family (9)

Citations (1)

Family Cites Families (14)

• 2013
  • 2013-09-09 CN CN201380056993.8A patent/CN104769983B/zh active Active
  • 2013-09-09 WO PCT/US2013/058818 patent/WO2014043040A1/en active Application Filing
  • 2013-09-09 JP JP2015531990A patent/JP2015534350A/ja active Pending
  • 2013-09-09 DE DE112013004444.7T patent/DE112013004444T5/de not_active Withdrawn
  • 2013-09-11 TW TW102132813A patent/TWI499316B/zh active
  • 2013-09-11 TW TW104124636A patent/TWI586185B/zh not_active IP Right Cessation
• 2017
  • 2017-02-20 JP JP2017029200A patent/JP6348624B2/ja not_active Expired - Fee Related

Patent Citations (1)

Non-Patent Citations (1)

Also Published As

Similar Documents

Legal Events