System and method for securely storing data in a SIM

Embodiments of the invention provide systems and methods for analyzing a Subscriber Identity Module (SIM) card, ascertaining multiple distally separated storable sections, and then securely storing data as an ordered list of storable sections representing a concatenated available storage on the SIM.

BACKGROUND

Secure storage of data on a mobile phone or device is increasingly difficult. Sophisticated means can be applied to extract information once sufficient privilege is obtained about the operating system onboard the mobile phone or device.

SUMMARY OF THE INVENTION

Embodiments of the invention provide systems and methods for analyzing a Subscriber Identity Module (SIM) card, ascertaining storable sections, and then securely storing data in them in a way where inspection of the SIM cannot reveal the data.

DETAILED DESCRIPTION

A SIM is a compartmentalized storage that is abstracted from the operating system on a mobile phone or device and cannot be accessed by normal means. Storage on the SIM is possible only via intervention by the mobile network operator.

The systems and methods disclosed herein teach how a process can be implemented for applications outside the mobile network operator boundary to store arbitrary data on a SIM. The disclosure also shows how to make such data hidden from other applications and SIM forensic devices. In addition, the systems and methods will show how to make the storage of data in each SIM unique, such that inspection of one SIM yields no information on how data is stored on all other SIMs. In practice, this method can be used to store any personal private information, such as encryption keys, banking details, health care records, and data from security applications installed on or off the device.

The following terms are used in the disclosure:

“SIM” refers to a Subscriber Identity Module, which is an integrated circuit that is intended to securely store data which are used to identify and authenticate subscribers on mobile devices. A SIM may also be implemented as a Universal Subscriber Identity Module (USIM).

“Secure SIM Server” refers to the application that keeps track of data allocation within a SIM.

“MNO” refers to a Mobile Network Operator, commonly known as the cellular company.

“ICCID” refers to the SIM international identity of its Integrated Circuit Card Identifier. ICCIDs are stored in the SIM cards and are also engraved or printed on the SIM card body during a process called personalization. The ICCID is defined by the ITU-T Recommendation E.118 as the Primary Account Number.

Other terms, unless defined here, refer to commonly known industry terms.

Every SIM/USIM card is a smart card containing a microprocessor, three types of memory, namely RAM, ROM and EEPROM, and some integrated logic to manage card security. The filesystem with all the non-volatile programmable data is stored in the EEPROM and has a hierarchical structure. The filesystem is organized as an n-ary tree with a root file called Master File (MF). Basically, there are two types of files: directories, called Dedicated Files (DF), and files, called Elementary Files (EF). Given the fact that the filesystem has a nested structure, it is important to know that a DF contains only a header, whereas an EF contains a header and a body.

The entire SIM/USIM filesystem can be mapped by a tool (SIM Extractor) that acquires the entire contents of a smart card memory. Using this tool, the following can be ascertained for each file:ID of the element;Standard name of an EF or DF;File type (e.g., MF, DF, or EF)Privileges, which are related to the constraints on the execution of a set of commands;Structure of file (e.g., transparent, linear fixed, or cyclic);Father of nodes, which are important to see the real structure of the n-ary tree; andSize of the files.

FIG.1illustrates a SIM filesystem mapping process according to one embodiment. A SIM Extractor102extracts a SIM binary image from SIM101. The SIM Extractor102notes the GSMA-standard-defined EFs, and the process concentrates on those files that are not part of the standard and yet have Update privilege. For this disclosure, these files (i.e., EFs with Update privilege) are called Writable EFs (WEF). Each SIM type will have a unique set of WEFs, and the total amount of writeable storage will vary from SIM type to SIM type. Generally, a 128 KB SIM may have up to 32 KB of WEFs available for storage. Larger SIMs may have even more. The size of each WEF is not the same and can range from 20 bytes to 10 KB.

Once the set of these WEFs are acquired by a SIM Image Function103, the list of WEF per SIM type are stored within the SIM Map database104within the Secure SIM Server105. Each SIM of the same type will have the same list of available WEFs. In practice, at a carrier, the number of types of SIM are limited since these are usually the result of large bulk orders.

FIG.2illustrates WEF Chaining in a SIM according to an example embodiment. The binary image of a SIM has been extracted and the filesystem map created. A root master file (MF3F00)231is the parent node to directory files, such as DF7F20 (221) and DF2F21 (222). DF7F20 (221) is the parent node for a plurality of elementary files (210). It will be understood thatFIG.2is a simplified illustration and that a SIM will have other directory files (DFs) under root file (MF)231. Each DF may be the parent to other DFs and/or elementary files (EFs). A USIM specification controls exactly the DF and EF that should be present on the SIM. Each EF has a very specific access policy defined. EF contents, location, and size are specified in 3GPP specifications. All SIMs must provide these writeable segments and the data structure contained therein are fixed by the specification.

WEFs are EFs that have update and read privileges but are not part of the specification. The WEFs may be accessed by users but make up a small segment of SIMs total capacity depending on SIM. Files201-205for the example SIM type illustrated inFIG.2are determined to be WEFs. With each set of WEFs, a filesystem can be created by chaining together the WEFs201-205. This can be done for each SIM by selecting a different chain of WEFs201-205as shown in theFIG.2.

A first WEF chain (dashed lines21) is created by linking the WEFs together in order: EF6F39 (201)→EF6F78 (202)→EF6F61 (203)→EF6F52 (204)→EF6FAE (205). A second WEF chain (dotted lines22) can be created by linking the WEFs together in a different order: EF6FAE (205)→EF6F61 (203)→EF6F52 (204)→EF6F39 (201)→EF6F78 (202).

There are a limited number of combinations for a given set of WEF's. However, the number of combinations is quite large since the number is based on the factorial count of the number of WEFs. A WEF count of N will yield N! such combinations or chains. For example, if there are 35 WEFs in a SIM, then there are 1.033×1040possible combinations or chains for that SIM.

In one embodiment, only the Secure SIM Server will know what chaining sequence of WEFs has been assigned to each SIM. Each SIM can be identified by a Mobile Station International Subscriber Directory Number (MSISDN), which in turn can be paired with a sequence of WEFs for that SIM or SIM type. It should be noted that even though each chain of WEFs is unique, the size of the storable area is the same for each SIM type.

FIG.1illustrates file allocation to a WEF Chain according to an example embodiment. For a filesystem to be mapped to each WEF Chain, fragments are constructed out of each WEF that is greater than some known size. In one embodiment, this size may be set at 256 bytes. Any fragments less than 256 bytes are then pooled together to create new 256-byte fragments.

The fragments are the basic building blocks of the filesystem. Several blocks can be allocated to form a file that can be used to store data. The number of blocks allocated depends on the size of the file, which is in multiples of the block size. Using a 256-byte block size, four blocks will store a 1 KB file. A block that is assigned from the pool to a file is recorded by the Secure SIM Server as allocated, while the others are marked as free (i.e., awaiting allocation).

The Secure SIM Server keeps track of the allocated and free blocks in each SIM and the composition and order of blocks that make up the file. The smallest file that can be created is the size of the block (i.e., 256 bytes) and the largest file depends on the number of free blocks available.

FIG.3illustrates WEF Chain21as shown inFIG.2, which comprises WEFs201-205. Each WEF can have a different size. For example, the sizes of WEFs201-205are 400, 1060, 1000, 1020, and 1640 bytes, respectively. When these WEFs are linked together, WEF Chain21has 5120 bytes total, which can be divided into twenty 256-byte blocks301. Data, such as File302(which is 1 KB in size) and File303(which is 2 KB in size) can be divided into a number of 256-byte fragments and stored in blocks301of WEF Chain21. For example, File302can be divided into four 256-byte fragments302a-d, which can then be stored in blocks301a-dof WEF Chain21. File303can be similarly divided into eight 256-byte fragments (303a-h) to be stored in blocks304a-hin WEF Chain21. The remaining eight blocks305in WEF Chain21are available to store up to 2 KB worth of additional data from one or more other files.

InFIG.3, File302has been divided into fragments that are stored in random locations of Chain21. The fragments301a-dof File302are interleaved with fragments304a-hof File303in Chain21, wherein the fragments304a-hof File303have been further interleaved with each other. To get the original File302and File303from Chain21, one would need to know: the WEF chain sequence, the size of each block, how each block is associated with each WEF (e.g., an EF address and offset for the start of each block), and then the sequence or series in which the fragments302a-dand303a-hare stored in particular blocks301. This becomes computationally impossible based upon the number of variables involved.

It should be noted that the superblock, which is the section of the file that keeps track of block allocation and file assignment is not on the SIM. The superblock is only stored on the Secure SIM Server. Therefore, only the Secure SIM Server stores the information required to determine which WEFs, and what offset in each WEF, is contributing to the block in a particular file. Without that map, it is almost impossible for a SIM forensic tool to ascertain the data that is resident on the SIM since the ordering of the data and indeed the total number of allocated blocks, is not known.

FIG.4is a flowchart illustrating Secure SIM Server401functions according to one embodiment. A SIM can be identified, for example, using an MSISDN or ICCID. To create a filesystem on the SIM, the Secure Image Function402communicates with the MNO network403to determine the type of SIM based on the ICCID of the SIM. Secure Image Function402then extracts the SIM's WEF list from SIM database404. The WEF list has been pre-determined at the time of the SIM personalization for this SIM type. Secure Image Function402then sends this WEF list data to the SIM Map Function405. SIM Map Function405creates a new file on the SIM by collecting available free blocks into a chain. SIM Map Function405then stores the SIM block map to SIM Map database406.

The filesystem created on the SIM is a series of bytes stored in various EFs. The actual locations of the bytes stored in various EFs are known only to the SIM Map Function405in the Secure SIM Server401. In one embodiment, a mechanism employed for reading and updating data from the WEFs is Remote File Management (RFM), which is a protocol defined by the GSM 03.48 standard.

FIG.5is a flowchart illustrating a SIM updating process. In an example embodiment, the file is a single WEF at 7F10/6F42. The Secure SIM Server401takes the following steps when an application requests to read/update the file content:

1) Receive, at a SIM Access Function501, a request for read or update on a file in the SIM by name (e.g., identify the SIM using an MSISDN or ICCID).

2) Refer to the SIM Map406and ascertain that the file is a single segment of 256 bytes located, for example, in the WEF 7F10/6F42 at a byte offset of 12.

3) Map the data to the WEF and offset list as a series of read/update operations.

4) Return the operations list.

5) Construct appropriate application protocol data unit (APDU) command for read/update of the file based on the list by the SIM Access Function501.

6) Send the APDU command from the SIM Access Function501over the air (OTA) to the device using binary SMS (e.g., the MSISDN of the SIM may be the reference in this case) via MNO network403. SIM Access Function501then receives the data as a response (in case of read), or a delivery notification (in case of an update).

This process results in the file on a SIM that is updated silently without the user of the device intervening or even being aware of the update. WEPs be accessed using standard Remote File Management protocol commands delivered using Binary SMS. The provisioning of GSM-specified EFs having dynamic content is a standard function at an MNO. For a large file, there may be several commands sent using multiple SMS deliveries. Each command may access a designated offset within the WEF list. When multiple commands are issued, the SIM Access Function501maintains transactional integrity by making sure that all the reads and writes are completed and then assembling the result.

An example method comprises imaging a SIM and mapping storage areas that are writable without overlap by standard GSM services. The method may further comprise chaining storage areas into a concatenated store that is unique to each SIM and defined by a storage location map that is kept secret. The method may further comprise storing data by dividing the store into segments and writing each segment at a place. The data may be compounded in a manner that is known only to originator.

Many modifications and other embodiments of the invention will come to mind to one skilled in the art to which this invention pertains having the benefit of the teachings presented in the foregoing descriptions, and the associated drawings. Therefore, it is to be understood that the invention is not to be limited to the specific embodiments disclosed. Although specific terms are employed herein, they are used in a generic and descriptive sense only and not for purposes of limitation.