When using AES CMAC for authentication of OTA messages, we must not pad
the user data before calling the CMAC function. This is unlike the DES
MAC, where padding to the DES block size is mandatory.
This bug was discovered when trying to talk OTA with AES to a
sysmoISIM-SJA5. This patch makes the OTA AES interoperate with the
card. Also, with this patch the cryptographic results of pySim/ota.py
are identical to those of the java code
org.opentelecoms.gsm0348.impl.crypto.CipheringManager
Change-Id: I4b40b5857f95ccb21c35795abe7a1995e368bac3
Unfortunately, TUAK requires a number of additional (and
differently-sized) parameters, so the format of EF.USIM_AUTH_KEY
differs significantly depending on TUAK or non-TUAK case.
Change-Id: I0dcfe05777510fb34973dc2259b137133d8e199d
This implicitly adds support for JSON->binary encoding, not just
decoding (previous code predating construct support).
Change-Id: I0994d9f66a504dd3c60b43ed5cf6645515dcbc6a
According to TS 23.003 Section 28.15 and 28.16 both GLI and GCI
are NAI as defined in IETF RFC 7542, which in turn specifies they
are encoded in UTF-8.
Change-Id: I0a82bd0d0a2badd7bc4a1f8de2c3e3c144ee5b12
This file is rather important for 5G SA operation, so we should have
a proper encoder/decoder in place.
Change-Id: I1b37fdfc2807976880b2cafb61951f08eebeb344
Also accept ProtocolError in addition to SwMatchError in filesystem.py
when probing for applications
Change-Id: I82b50408328f8eaaee5c9e311c4620d20f930642
The cards are 99% software-compatible to the SJA2, so let's just
derive the SJA5 class from the SJA2
Change-Id: I706631baaf447c49904277886bc9a3f6ba3f5532
DF.SAIP (SIMalliance Interoperable Profile) is not part of 31.102,
but something from the eSIM/eUICC universe of TCA (formerly known as
SIMalliance). However, as 3GPP does not specify how/where the card
stores the information required for SUCI calculation, the
TCA/SIMalliance standard is the only standard there is. Some CardOS
start to use this standard even for non-eSIM/eUICC use cases.
Change-Id: Iffb65af335dfdbd7791fca9a0a6ad4b79814a57c
The FID in ADF.USIM is different from the FID in DF.GSM. So while
we can re-use the ts_51_011 EF_NIA class definition, we must pass in
a different fid to the constructor.
Change-Id: Ib414d5b476666e276824266e33b341175a2ee05a
Just like the existing commands for UST/IST: Allow the user to
activate/deactivate individual services. As EF.SST also contains
information about "allocation" of a service, let's have commands for
allocation and activation.
Change-Id: If959d06248cb1a9d2c0a21cdd40d438726cbc5f0
R-UIM (CDMA) cards are pretty much like the normal GSM SIM cards and
"speak" the same 2G APDU protocol, except that they have their own file
hierarchy under MF(3f00)/DF.CDMA(7f25). They also have DF.TELECOM(7f10)
and even DF.GSM(7f20) with a limited subset of active EFs. The content
of DF.CDMA is specified in 3GPP2 C.S0023-D.
This patch adds a very limited card profile for R-UIM, including auto-
detecion and a few EF definitions under DF.CDMA. This may be useful
for people willing to explore or backup their R-UIMs. To me this was
useful for playing with an R-UIM card from Skylink [1] - a Russian
MNO, which provided 450 MHz CDMA coverage until 2016.
[1] https://en.wikipedia.org/wiki/Sky_Link_(Russia)
Change-Id: Iacdebdbc514d1cd1910d173d81edd28578ec436a
Even though _bit_byte_offset_for_service() is a @staticmethod, it's
still available via self, just like any non-static method.
Change-Id: I3590dda341d534deb1b7f4743ea31ab16dbd6912
Depending on the card type (SIM or USIM/ISUM), self.cla_byte may
be either 0xa0 or 0x00. Sending RUN GSM ALGORITHM with CLA=0x00
fails with SW=6985 (Command not allowed), so let's make sure
that we always use CLA=0xa0 regardless of the card type.
Change-Id: Ia0abba136dbd4cdea8dbbc3c4d6abe12c2863680
This adds pySim-shell support for the RESIZE FILE command in order
to change the size of linear fixed or transparent EF.
Change-Id: I03fbb683e26231c75f345330ac5f914ac88bbe7a
EF.EST is the *enabled* services table. Let's call the shell commands
enable and disable, rather than activate/deactivate.
Change-Id: Iacbdab42bc08e2be38ad7233d903fa7cda0d95b6
sysmo-isim-sja2 may come in different configurations, so some may
intentionally lack ADF.USIM or ADF.ISIM. Since select_adf_by_aid() may
raise an exception when selecting a non existent file we should make
sure that the ADF we intend to select is indeed present. A reliable way
to do this is to check if the application is registered in EF.DIR.
Change-Id: Icf6f6b36f246398af408ec432d493fe3f22963dd
Lets add test vectors for the per-record/per-file encode/decode of
our various classes for the Elementary Files.
We keep the test vectors as class variables of the respective EF-classes
to ensure implementation and test vectors are next to each other.
The test classes then iterate over all EF subclasses and execute the
decode/encode functions using the test vectors from the class variables.
Change-Id: I02d884547f4982e0b8ed7ef21b8cda75237942e2
Related: OS#4963
This fixes a regression introduced in Change-Id
I02d6942016dd0631b21d1fd301711c13cb27962b which added support for
different encoding/decoding of records by their record number.
Change-Id: I0c5fd21a96d2344bfd9551f31030eba0769636bf
The encoder function apparently was never tested, it didn't match at all
the output of the decoder, not even in terms of the string keys of the
dict.
Change-Id: Id67bc39d52c4dfb39dc7756d8041cbd552ccbbc4
ValidityPeriodAdapter() must return integer values when encoding a
value, as only integer values can be expressed in the binary format.
Change-Id: I0b431a591ac1761d875b5697a71b6d59241db87d
As per EIRENE GSM-R SIM-Card FFFIS, EF_IC conatains records of 1+2+2+2
bytes, the network string table index is 16bit and not 8bit as we
implemented so far.
Change-Id: I9e3d4a48b3cb6fb0ecf887b04c308e903a99f547
When decoding the SELECT response of a clasic GSM SIM without
UICC functionality, we
* did not decode the record length or number of records
* accidentially reported the EF file_size as available_memory (like DF)
Let's fix those two, and also add a comment on how the output dict
of decode_select_response() should look like.
As a result, code like 'read_records' now knows the number of records
and can iterate over them rather than raising exceptions.
Change-Id: Ia8e890bda74e3b4dacca0673d6e5ed8692dabd87
Closes: OS#5874
This file is a optional file specified by TS 51.011, storing the last
numbers dialled. As the EIRENE FFFIS for GSM-R SIM refers to this,
we must implement it to have full GSM-R support in pySim.
Change-Id: I3b7d6c7e7504b7cc8a1b62f13e8c0ae83a91d0f0
Related: OS#5784
We're using a shared class to implement the identical file encoding
for EF.{ADN,SDN,MBDN,BDN,FDN,CFIS}. However, they all point to
different extension files.
Previosly for EF.SDN:
"ext1_record_id": 255
Now for EF.SDN:
"ext3_record_id": 255
Change-Id: I5301d41225266d35c05e41588811502e5595520d
Related: OS#5784
TS 51.011 specifies an "Extended BCD Coding" in Table 12 of Section
10.5.1. It allows to express the '*' and '#' symbols used in GSM
SS and/or USSD codes.
This improves decoding from
"dialing_nr": "a753b1200f",
to
"dialing_nr": "*753#1200f",
Change-Id: Ifcec13e9b296dba7bec34b7872192b7ce185c23c
Related: OS#5784
DF.TELECOM/EF.SDN (Service Dialling Numbers) is specified in section
10.5.9 of TS 51.011 and required by EIRENE for GSM-R.
Let's use the pre-existing EF.ADN decoder to decode this file.
Change-Id: If91332b10138096d465a9dccf90744de2c14b2be
Related: OS#5784
Those files contain a bit-mask of active group IDs stored at the
respective positions in EV.VGCS and EF.VBS. However, the bit-order
of each byte is reversed.
Change-Id: I77674c23823aae71c9504b1a85cd75266edadc6f
Related: OS#5784
In their infinite wisdom, the authors of the EIRENE FFFIS for GSM-R SIM
cards invented yet a new way of encoding data in SIM card files: The
first record of a file may be encoded differently than further records
of files.
This patch implements the feature based on the newly-introduced way by
which we pass the record number to the encoder and decoder methods.
Change-Id: Ib526f6c3c2ac9a945b8242e2e54536628376efc0
Related: OS#5784
In their infinite wisdom, the authors of the EIRENE FFFIS for GSM-R SIM
cards invented yet a new way of encoding data in SIM card files: The
first record of a file may be encoded differently than further records
of files.
Let's add the required infrastructure to pySim so that the encode and
decode methods for record-oriented files get passed in the current
record number.
Change-Id: I02d6942016dd0631b21d1fd301711c13cb27962b
Related: OS#5784
This fixes the below exception when trying to decode records of EF.FN:
EXCEPTION of type 'TypeError' occurred with message: 'unsupported operand type(s) for &: 'str' and 'int''
Change-Id: I3723a0d59f862fa818bea1622fe43a7b56c92847
Related: OS#5784
So far we supported
* GSMTAP live traces via a UDP socket
* RSPRO traces from pcap files (or live)
We were lacking support for reading GSMTAP stored in pcap, which
is what this patch implements.
Change-Id: I46d42774b39a2735500ff5804206ddcfa545568c
DF.GSM and ADF.USIM have an EF.AD with nearly the same contents. Usually
there is one file physically present and the other is just a link.
Apparantly this is not always the case for sysmo-ismi-sja2 cards, so
lets program EF.AD in both locations.
Change-Id: Ic9dd4acc8d9a72acbb7376ddf3e2128125d4a8f5
Related: OS#5830
Since we now ensure that mnc always has a valid length lets make the
check in cards.py more strict.
Related: OS#5830
Change-Id: Iee8f25416e0cc3be96dff025affb1dc11d919fcd
The decoder/encoder of that decodes the EF.xSIM_AUTH_KEY files has an
overcomplicated handling for op/and opc. There is a condition that
checks if milenage is configured and another one that checks if the
string is recognized as OP or OPc. Both is not correct and seems not to
work (op and opc is always displayed as "null")
The encoder/decoder should focus on the physical file layout and
regardless of any other conriguration the OP/OPc field is physically
present and should be displayd and presented for editing.
Change-Id: I6fa3a07e5e473273498d3f13d4cfa33743b787e1