MIFARE Application Directory

Coding of the application directories:

MAD version numbers:
This standard proposes MAD version 1, 2 and 3.
For MAD1 and MAD2 the version number is encoded in the GPB (see chapter General purpose byte (GPB)). For MAD3 the version number is coded in a special file (see chapter MAD and MIFARE DESFire). For future MIFARE cards this MAD standard may change together with the version numbering.
MAD types:
This standard allows 3 types of MAD:
-monoapplication card without directory entries
-monoapplication card with directory entries
-multiapplication card with directory entries
The MAD type is encoded in the GPB.
Function clusters:
Function cluster codes enable easy classification of applications. Currently used codes may be found in annex C. Any organization requesting for a new AID may suggest a code out of this list. If this information is missing the registration authority will determine the code.
Administration codes:
Function cluster code 00 hex assigns specific administration codes to the corresponding
AID – administration codes:
00 00 hexsector is free
00 01 hexsector is defect, e.g. access keys are destroyed or unknown
00 02 hexsector is reserved
00 03 hexsector contains additional directory info (useful only for future cards)
00 04 hexsector contains card holder information in ASCII format.
00 05 hexsector not applicable (above memory size)
Card holder information:
The administration code 0×00 0×04 indicates to public card holder information in the corresponding sector. There is no binding rule but just the following recommendation given for storing card holder information using RLC (Run-Length-Coding):

Table 7. Card holder information              
                bit7   bit0
byte n   byte n-1   …………. byte 1     byte 0  
00   last character     character 1 type length  
byte 0:length= lower 6 bit (number of used bytes including 0×00, max. 63)    
type = highest 2 bit (00=surname; 01=given name; 10=sex; 11=any other data)    
byte 1 to :ASCII text as specified in type (first character at byte 1; ends with 0×00)  
Unused bytes should be set to 0×00. For storing the sex the following convention is  
suggested – use „m“ (code 0x6D) for masculine and „f“ (code 0×66) for feminine. In case of
insufficient storage space in one sector the card holder information may be continued in  
the next sector referenced by the administration code 0×00 0×04.      
given name:Philip                  
all data is readable with key A but key B is necessary for writing.      


The hexadecimal contents of the corresponding sector should look like this:

Table 8. Hexadecimal contents                        
byte byte byte byte byte byte byte byte byte byte byte byte byte byte byte byte
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
6C 69 68 50 47  00  6E  61  6D  65  6C  70  6D  61  53  0a
00  00  00  00  00  00  00  00  00  00  38 37 36 35 2F  34
69 88 77 78 a5  a4  a3  a2 a1 a0
The card issuer is responsible for appropriate key protection of card administration            
sectors. It is advisable to protect all sectors of the card against unauthorized writing with          
secret keys B. This is recommended even for free and unused sectors.                
In special cases, for example when storing public card holder information this data may be          
released for public reading using the default key A: a0a1a2a3a4a5 hex.