tomasz-lisowski/swsim

RUN GSM ALGORITHM command implementation

edbek opened this issue · 1 comments

edbek commented

When testing swsim, I tried to work with the key Ki (request command RUN GSM ALGORITHM). And there were comments:

  1. the Ki key is inside the apduh_gsm_gsm_algo_run() function in the apduh.c file. As far as I understand this is a temporary solution. It is possible that you need to bring this key to a more convenient place.

  2. the old COMP128 version 1 algorithm is used, and not the latest COMP128 version 3 (the latest version can be taken from libosmocore/src/gsm/comp128v23.c). Are you willing to add this last algorithm?

  3. when checking this RUN GSM ALGORITHM command through osmo-sim-auth.py, it turned out that the byte order in the key was violated, or it was made so that it was visually accepted as correct. Is it so ?

That is, in your code:

uint8_t const ki[16] = {
0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF,
0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0x07,
};

byte 0x07 is the highest index, and visually it is the key Ki is represented as 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF07, that is, byte 0x07 in this case is the least significant.

For the user, it is possible to enter the Ki key into your project as a string, for example, as:

uint8_t Ki_str[] = {"0xFFFFFFFFFFFFFFFFFFFFFFFFFFFF07"};

and the key as:
int8_t Ki[16] = {0};

and get Ki[] from Ki_str[] using the function:

for (i=0; i<16; i++) {
Ki[i] = (hextoint(Ki_str[2i+2])<<4) | hextoint(Ki_str[2i+3]);
}

,where

hextoint(char x)
{
x = toupper(x);
if (x >= 'A' && x <= 'F') {
return(x-'A'+10);
}
else if (x >= '0' && x <= '9') {
return(x-'0');
}
}

Then we will have the correct visual representation of the key as Ki_str[] and the correct location of the binary key Ki[16] in memory.

I don't have time right now, but I actually intended to add the KI to the file system, a bit like the KC. The issue is that unlike with EF.KC, there is no standardized EF.KI file ID which means I'd need to add something like DF.SYSTEM. Commercial SIM cards often have a hidden DF like that to store the non-standard files required for the operation of the SIM. The alternative is to use an unused file ID, but that wouldn't be very elegant.

Also, the GSM authentication is something I didn't really test (due to lack of time), so thanks for pointing out the issues with that.

Feel free to make a pull request if you'd like to see this added sooner ;). I use clangd for formatting all the files (the config file is present in the root already). Conversion of a hex string to bytes is already present in swICC as that is a functionality I use when generating the internal representation of the file system.