FreeCalypso > hg > fc-sim-tools
comparison doc/GrcardSIM2-WEKI-file @ 18:da6e9d0b2ee6
data, doc, scripts: import from previous fc-pcsc-tools repo
author | Mychaela Falconia <falcon@freecalypso.org> |
---|---|
date | Sun, 14 Mar 2021 07:57:09 +0000 |
parents | |
children | 526193acfb3f |
comparison
equal
deleted
inserted
replaced
17:372ecc4aa2c4 | 18:da6e9d0b2ee6 |
---|---|
1 GrcardSIM2 cards have a proprietary EF under DF_GSM with file ID 0x0001; | |
2 Osmocom wiki page for this card model gives EF.WEKI as the name for this | |
3 proprietary file. We (FreeCalypso) have no idea as to where this name came | |
4 from, and where and how the people who wrote that wiki page (Sysmocom staff or | |
5 not - unknown) got this knowledge. This file is important because it stores Ki | |
6 and the selection of COMP128 algorithm version, but the same file also appears | |
7 to have other fields serving other purposes which are not currently understood. | |
8 | |
9 The total length of this transparent EF is 35 bytes, out of which only the first | |
10 19 bytes are documented in the Osmocom wiki page and written by their pySim-prog | |
11 tool. Let us now break down this file according to our currently available | |
12 limited understanding: | |
13 | |
14 * The first two bytes are always 00 10 - these byte values appear in "blank" | |
15 unprogrammed cards as shipped by Grcard, they also appear in the Osmocom wiki | |
16 page, and are programmed by pySim-prog. The purpose and meaning of these two | |
17 bytes are completely unknown, and we have never tried writing anything | |
18 different into them. | |
19 | |
20 * The next byte gives COMP128 algorithm selection plus something else that is | |
21 not understood: | |
22 | |
23 - The low 2 bits of this byte select COMP128 algorithm version as follows: | |
24 | |
25 0b00 = COMP128v1 | |
26 0b01 = COMP128v2 | |
27 0b10 = COMP128v3 | |
28 | |
29 Note that the Osmocom wiki page is wrong in its description of these bits: | |
30 setting these two bits to 0b11 ends up selecting COMP128v2 rather than v3. | |
31 (pySim-prog is unaffected because it always writes 00 into the whole byte, | |
32 selecting COMP128v1.) | |
33 | |
34 - The remaining 6 bits of this byte are not understood. Osmocom wiki page | |
35 tells people to write zeros into the upper 6 bits and so does pySim-prog, | |
36 but the "blank" unprogrammed cards we got from Grcard have this byte set to | |
37 0x20. Setting the upper nibble to either 0 or 2 does not seem to affect | |
38 the result of RUN GSM ALGORITHM operations, thus it probably controls | |
39 something else. | |
40 | |
41 * The next 16 bytes store Ki - this part is straightforward. | |
42 | |
43 * The last 16 bytes are not understood; our "blank" unprogrammed cards from | |
44 Grcard have all FFs in these bytes. | |
45 | |
46 fc-simtool support for programming Ki and COMP128 algorithm selection | |
47 ===================================================================== | |
48 | |
49 Even if we never learn the function of the other mysterious fields of EF.WEKI, | |
50 we must be able to program our own Ki and make our own selection of COMP128 | |
51 algorithm version in order to use these programmable SIM cards with our own GSM | |
52 networks. The following solution has been implemented for immediate use: | |
53 | |
54 * Our grcard2-set-comp128 command takes a single argument of 1, 2 or 3, | |
55 selecting COMP128 algorithm version. The implementation of this command | |
56 selects EF.WEKI, reads the previous content of the magic byte at offset 2, | |
57 keeps the upper 6 bits unchanged, and writes the new COMP128 algorithm | |
58 selection into the low 2 bits. If we ever learn the meaning of other bits, | |
59 we'll be able to add new orthogonal commands that manipulate those other bits, | |
60 but leave COMP128 selection unchanged. | |
61 | |
62 * Our grcard2-set-ki command writes 16 bytes at offset 3, leaving all other | |
63 bytes untouched. |