FreeCalypso > hg > fc-sim-tools

comparison doc/GrcardSIM2-WEKI-file @ 76:526193acfb3f

Find changesets by keywords (author, files, the commit message), revision number or hash, or revset expression.
doc/GrcardSIM2-WEKI-file: update with knowledge from doc/vendor/grcard2-person-script
author Mychaela Falconia <falcon@freecalypso.org>
date Fri, 09 Apr 2021 02:01:47 +0000
parents da6e9d0b2ee6
children dc772132b5c9
comparison
equal deleted inserted replaced
75:42229bec887b 76:526193acfb3f
4 from, and where and how the people who wrote that wiki page (Sysmocom staff or 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 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 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. 7 to have other fields serving other purposes which are not currently understood.
8 8
9 When we (FreeCalypso) asked Grcard about this proprietary file, they sent us a
10 "personalization" command script which we have archived in this code repository
11 under doc/vendor/grcard2-person-script; this script is a sequence of command
12 APDUs (raw hex with minimal comments) for an example card programming. The
13 proprietary file in question is named GSM_KI in this script; the origin of the
14 name EF.WEKI that appears in the Osmocom wiki page is still unknown.
15
9 The total length of this transparent EF is 35 bytes, out of which only the first 16 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 17 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 18 tool. Interestingly enough, Grcard's "personalization" command script also
12 limited understanding: 19 writes only the first 19 bytes. Let us now break down this file according to
20 our currently available limited understanding:
13 21
14 * The first two bytes are always 00 10 - these byte values appear in "blank" 22 * 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 23 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 24 page, and are programmed by pySim-prog. The "personalization" script we got
17 bytes are completely unknown, and we have never tried writing anything 25 from Grcard also programs the same 00 10 in these two bytes. The purpose and
18 different into them. 26 meaning of these two bytes are completely unknown, and we have never tried
27 writing anything different into them.
19 28
20 * The next byte gives COMP128 algorithm selection plus something else that is 29 * The next byte gives COMP128 algorithm selection plus something else that is
21 not understood: 30 not understood:
22 31
23 - The low 2 bits of this byte select COMP128 algorithm version as follows: 32 - The low 2 bits of this byte select COMP128 algorithm version as follows:
30 setting these two bits to 0b11 ends up selecting COMP128v2 rather than v3. 39 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, 40 (pySim-prog is unaffected because it always writes 00 into the whole byte,
32 selecting COMP128v1.) 41 selecting COMP128v1.)
33 42
34 - The remaining 6 bits of this byte are not understood. Osmocom wiki page 43 - 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, 44 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 45 the "personalization" command script we got from Grcard also writes zeros
37 0x20. Setting the upper nibble to either 0 or 2 does not seem to affect 46 into these upper 6 bits. However, if one orders "blank" or unprogrammed
38 the result of RUN GSM ALGORITHM operations, thus it probably controls 47 cards from Grcard like we do, the initial "unprogrammed" state of this byte
39 something else. 48 is 0x20, as one can see in the data/grcard2-blank-state dump.
49
50 Setting the upper nibble to either 0 or 2 does not seem to affect the
51 result of RUN GSM ALGORITHM operations, thus it probably controls something
52 else - or perhaps that bit controls nothing at all, and the "unprogrammed"
53 state is merely a bogon - we have no way of knowing.
40 54
41 * The next 16 bytes store Ki - this part is straightforward. 55 * The next 16 bytes store Ki - this part is straightforward.
42 56
43 * The last 16 bytes are not understood; our "blank" unprogrammed cards from 57 * The last 16 bytes are not understood; our "blank" unprogrammed cards from
44 Grcard have all FFs in these bytes. 58 Grcard have all FFs in these bytes.