comparison doc/GrcardSIM2-WEKI-file @ 100:dc772132b5c9

doc/GrcardSIM2-WEKI-file: document mechanism and policy changes regarding the upper 6 bits of the mystery byte
author Mychaela Falconia <falcon@freecalypso.org>
date Wed, 05 May 2021 05:22:28 +0000
parents 526193acfb3f
children
comparison
equal deleted inserted replaced
99:97ba63d9361a 100:dc772132b5c9
61 ===================================================================== 61 =====================================================================
62 62
63 Even if we never learn the function of the other mysterious fields of EF.WEKI, 63 Even if we never learn the function of the other mysterious fields of EF.WEKI,
64 we must be able to program our own Ki and make our own selection of COMP128 64 we must be able to program our own Ki and make our own selection of COMP128
65 algorithm version in order to use these programmable SIM cards with our own GSM 65 algorithm version in order to use these programmable SIM cards with our own GSM
66 networks. The following solution has been implemented for immediate use: 66 networks. The following solution has been implemented in the absence of better
67 documentation:
67 68
68 * Our grcard2-set-comp128 command takes a single argument of 1, 2 or 3, 69 * Our grcard2-set-comp128 command takes one or two arguments; the first argument
69 selecting COMP128 algorithm version. The implementation of this command 70 must be 1, 2 or 3, selecting COMP128 algorithm version, whereas the second
70 selects EF.WEKI, reads the previous content of the magic byte at offset 2, 71 optional argument gives the value to be written into the upper 6 bits of the
71 keeps the upper 6 bits unchanged, and writes the new COMP128 algorithm 72 mystery byte. The operation of this command always begins with selecting
72 selection into the low 2 bits. If we ever learn the meaning of other bits, 73 EF.WEKI, but then differs depending on whether or not the optional second
73 we'll be able to add new orthogonal commands that manipulate those other bits, 74 argument was given. If only the COMP128 version argument was given, our
74 but leave COMP128 selection unchanged. 75 command reads the previous content of the magic byte at offset 2, keeps the
76 upper 6 bits unchanged, and writes the new COMP128 algorithm selection into
77 the low 2 bits. OTOH, if two arguments are given, then our command writes
78 the whole byte without reading its previous value; the first argument sets
79 the COMP128 algorithm version and the second argument sets the non-understood
80 upper 6 bits. The second argument is always interpreted as hex and must be
81 in the range between 00 and FC, with the low 2 bits clear.
75 82
76 * Our grcard2-set-ki command writes 16 bytes at offset 3, leaving all other 83 * Our grcard2-set-ki command writes 16 bytes at offset 3, leaving all other
77 bytes untouched. 84 bytes untouched.
85
86 Practical choice for the upper 6 bits of the mystery byte
87 =========================================================
88
89 Following the principle of separation of mechanism and policy, our
90 grcard2-set-comp128 command allows the upper 6 bits of the mystery byte to be
91 either set explicitly or left unchanged. However, for actual operational use
92 of our FCSIM1 cards with our own GSM networks with COMP128v3, should we set the
93 complete byte to 0x02 or to 0x22? Based on the official "personalization"
94 script from Grcard, I (Mother Mychaela) have decided to write zeros into the
95 non-understood upper 6 bits, and this policy choice is embodied in our
96 fcsim1-defprog command script.