Smart card contactless module:

 Mifare Plus X 4K Pre-printed Cards,Mifare Plus X 4K Printing Cards,RFID Mifare Plus X 4K Cards,ISO Mifare Plus X 4K Card, 

Bonding pad assignments to smart card contactless module
Contactless interface module MF1PLUSx0y1DA4/03 and /13
Antenna contacts Symbol Description
LA LA antenna coil connection LA
LB LB antenna coil connection LB

 —————————————————————————————————————————————-

SMART CARD FILES
In addition to containing mechanisms for identification and authentication, smart cards are primarily data storage media. They have a decisive advantage relative to other storage media, such as diskettes, in that access to the data can be tied to certain conditions. The first smart cards had only more or less directly addressable memory regions, which could be used for writing or reading data. The data were accessed by specifying physical memory addresses. Nowadays, all smart cards have complete hierarchical file management systems with symbolic, hardware-independent addressing. Naturally, these file management systems have certain features that are specific to smart cards. The most obvious feature is that there is no man–machine interface. All files are addressed using hexadecimal codes, and all commands are strictly based on this addressing, since here communication only takes place between two computers. Equally typical of these file management systems is that they are designed to use a small amount of memory. Every redundant byte is avoided if possible. Since the ‘user’ in the terminal is a computer, this does not present any problems. There is usually no form of sophisticated memory management, which also helps to keep memory usage as low as possible. If a file is deleted – and only a few operating systems have this capability – the space released does not necessarily become available for use by a newly created file. Normally, all files are created and loaded into the smart card when it is initialized or personalized. After this, changes to file contents are limited. Naturally, the characteristics of the memory that is used also affect the nature of the file management system. The memory pages in an EEPROM cannot be written or erased an unlimited number of times, as can the hard disk of a PC. Consequently, there are special file attributes that allow information to be stored redundantly so it can be corrected if necessary.

Internal structures of files
Modern file management systems for smart cards have an object-oriented structure. This means that all information about a file is stored in the file itself.Afurther consequence of this principle is that a file must always be selected before any action can be performed. Files in such objectoriented systems are thus always divided into two parts. The first part, called the file header, contains information about the layout and structure of the file and its access conditions. The modifiable user data are stored in the second part, the file body, which is linked to the file header by a pointer. In addition to providing improved data structuring, this scheme also has the advantage of providing better physical security for data items. The page-oriented EEPROM containing all the files allows only a limited number of write/erase cycles. The file header and the file body are always located on separate memory pages. The header, which is normally rarely altered, stores all of the access conditions. A write or erase error involving the file body thus cannot affect these conditions. If the header and the file body were located in the same page of memory, it would be possible to utilize deliberately generated write errors to alter the access conditions such that confidential information could be read from the file body. Some smart card operating systems offer the option of addressing a file body from two different headers. These two headers are usually located in DFs belonging to two different applications. This allows data to be shared between two applications in a technically elegant manner. In this case, it is important for the access conditions specified in the two headers to be identical.

File types
The structure of a smart card file system, as specified in the ISO/IEC 7816-4 standard, is similar to that of a DOS or Unix system. The major difference is that smart cards do not contain any application-specific files, such as special types of files for a particular word processor. Only the standard file structures may be used in smart cards. There are basically two categories of files for file smart cards. The first category is directory files, which are called ‘dedicated files’ (DFs). The second category consists of the files that hold the actual user data, which are called ‘elementary files’ (EFs). A DF acts as a sort of folder containing other, lower level DFs or EFs that logically belong together. EFs can be classified into those for the external world (working EFs) and those for the operating system (internal EFs). The various file types are described below, and their relationships are illustrated in Figure 5.14.

MF
The root directory is called the ‘master file’ (MF). It is implicitly selected after the smart card is reset. The MF contains all other directories and all files. It is a special type of DF, and it represents the entire extent of the smart card memory available for the file region. A master file must be present in every smart card.

DF
Dedicated files (DFs) may exist belowtheMFas needed. The term ‘directory files’ is frequently used for these files, although this does not comply with the official definition of the abbreviation ‘DF’ in the ISO/IEC 7816-4 standard. A DF is a directory in which other files (DFs and EFs) can be grouped together. A DF may contain other DFs. In principle, there is no limit on the number of levels of DFs. However, it is rare for there to be more than two levels of DFs under the MF, due to the limited amount of memory in smart cards. With the specification for the UICC (TS 102.221), a special type of DF was introduced with the name ‘application dedicated file’ (ADF). This is a DF for applications, and it can be selected using an appropriate mechanism (a SELECT command with an AID), but it is not located below the MF. An ADF can thus be considered to be a type of MF.

EF
The user data needed for an application are located in EFs. ‘EF’ is the abbreviation of ‘elementary file’. EFs may be located directly below the MF or below a DF. To allow data to be stored in a minimum amount of memory and logically optimized data structures, an EF always has an internal file structure. This is the main difference between EFs and files in a PC, whose internal data structures are determined by applications (such as word processors) rather than by the operating system. EFs are classified into working EFs and internal EFs.

Working EFs
All application data that must be read by or written from the terminal, or in other words, all data that are intended for the external world (as seen by the smart card), are located in working EFs. The data contained in such files are not used by the operating system.

Internal EFs
In addition to EFs for applications, there are also internal system files that store data for the operating system itself, data for the execution of an application, secret keys and program code. Access to these data is specially protected by the operating system. According to ISO/IEC 7816-4, these system files can be integrated into the file management system in two different ways. The first option is to store these files in the relevant application DFs as invisible EFs. Such files cannot be selected, and they are managed fully transparently by the smart card operating system in a manner similar to how resource files are used in the Macintosh OS. With the second option, these system files are assigned regular file names (in other words, FIDs) and can be selected using these names. This is essentially the same principle as is used for file management under DOS. Each of these two approaches has an equal number of advantages and disadvantages, with both providing the same functionality in somewhat
different manners.

Application files
According to convention, all files containing user data for a particular application (the EFs for that application) are always grouped together in a single DF. This produces a clear and easily understood structure, and it makes it easy to enter a new application into a smart card by creating the appropriate DF. Since the MF is a special sort of DF, it goes without saying that in a single-application smart card, all the application files can be placed directly under theMF. In a typical single-application smart card, therefore, all the EFs can be located either directly under the MF or in a solitary DF. Smart cards with several applications have a corresponding number of DFs, in which the EFs belonging to the applications are located. Additional DFs can be placed within such application DFs. For example, a DF placed directly under the MF could be dedicated to a ‘Traffic Control’ application. An additional level of DFs within the application DF could contain the files for the languages supported, such as ‘English’ and ‘Deutsch’.