This adds an implementation of the GlobalPlatform SCP03 protocol. It has
been tested in S8 mode for C-MAC, C-ENC, R-MAC and R-ENC with AES using
128, 192 and 256 bit key lengh. Test vectors generated while talking to
a sysmoEUICC1-C2T are included as unit tests.
Change-Id: Ibc35af5474923aed2e3bcb29c8d713b4127a160d
I'm not entirely sure if this is the right thing to do. For sure I do
have cards which don't like SELECT with C-MAC appended... and
GlobalPlatform clearly states SELECT is coded with CLA value that has
the MSB not set (i.e. not a GlobalPlatform command).
Change-Id: Ieda75c865a6ff2725fc3c8772bb274d96b8a5a43
This implementation of GlobalPlatform SCP02 currently only supports
C-MAC and C-ENC, but no R-MAC or R-ENC yet.
The patch also introduces the notion of having a SCP instance associated
with a SimCardCommands instance. No code is using this yet, it will be
introduced in a separate patch.
Change-Id: I56020382b9dfe8ba0f7c1c9f71eb1a9746bc5a27
Let's simply use the matchingId for filesystem lookup of the UPP file.
This way we can have any number of profiles by simply creating the
respeective files.
Change-Id: I0bc3a14b9fdfcc6322917dd0c69d8295de486950
The DGI encoding is specified in Annex B of the
"GlobalPlatform Systems Scripting Language Specification v1.1.0"
which is an "archived" specification that is no longer published
by GlobalPlatform, despite it being referenced from the GlobalPlatform
Card Specification v2.3, which is the basis of the GSMA eSIM
specifications.
For some reason it was the belief of the specification authors that
yet another format of TLV encoding is needed, in addition to the BER-TLV
and COMPREHENSION-TLV used by the very same specifications.
The encoding of the tag is not really specified anywhere, but I've only
seen 16-bit examples. The encoding of the length is specified and
implemented here accordingly.
Change-Id: Ie29ab7eb39f3165f3d695fcc1f02051338095697
This commit introduces the capability to parse and encode
SimAlliance/TCA "Interoperable Profiles" and apply personalization
operations on them.
Change-Id: I71c252a214a634e1bd6f73472107efe2688ee6d2
This commit introduces
* the osmo-smdpp.py program implementing the main procedures and the
HTTP/REST based ES9+
* python modules for ES8+ and non-volatile RSP Session State storage
* the ASN.1 source files required to parse/encode RSP
* 3GPP test certificates from SGP.26
* an unsigned profile package (UPP) of a SAIP v2.3 TS48 test profile
As I couldn't get the 'Klein' tls support to work, the SM-DP+ code
currently does not support HTTPS/TLS but plan HTTP, so you either have
to modify your LPA to use HTTP instead of HTTPS, or put a TLS proxy in
front.
I have successfully installed an eSIM profile on a test eUICC that
contains certificate/key data within the test CI defined in GSMA SGP.26
Change-Id: I6232847432dc6920cd2bd08c84d7099c29ca1c11
This is the protocol used for the ES8+ interface between SM-DP+ and the
eUICC in the GSMA eSIM system.
Change-Id: Ic461936f2e68e1e6f7faab33d06acf3063e261e7
We cannot fully switch to construct for all of it easily due to
the priority value and the ordering/sorting by priority implemented
in the hand-coded version. But we can at least migrate the
encode/decode of the hnet_pubkey_list via construct.
Change-Id: I4ad5ea57bab37c2dc218e7752d538aa4cdc36ee3
It's customary in the SIM card universe to right-pad data with ff bytes.
So far we only test decoders without such padding, which is unrealistic.
Let's also tests the decoders with extra 'ff' padding present.
For some files this doesn't make sense, so we add a _test_no_pad class
attribute that can be spcified to prevent this new "test with ff-padding"
from being executed for the test data of the class.
Change-Id: I7f5cbb4a6f91040fe9adef9da0a1f30f9f156dae
TS 102 221 Annex A defines three variants of encoding UCS-2 characters
into byte streams in files on UICC cards: One rather simplistic one, and
two variants for optimizing memory utilization on the card.
Let's impelement a construct "Ucs2Adapter" class for this.
Change-Id: Ic8bc8f71079faec1bf0e538dc0dfa21403869c6d
While we do have the _test_de_encode data driven tests for file
definitions, we don't yet have something similar for derived classes of
BER_TLV_IE. This means that TLVs used outside of the filesystem context
(for example, decoding the SELECT/STATUS response, but also eUICC and
other stuff) do not yet have test coverage.
This commit just adds the related test code, but no test data yet.
Related: OS#6317
Change-Id: Ied85f292bb57fde11dc188be84e3384dc3ff1601
on some systems, the output would otherwise contain colored status
words, which in turn mean the test otuput no longer matches the expected
output.
Change-Id: Icb700f6e85a285748e00367a398975aa5e75dec5
There are some pretty intricate rules about how GSM and E-UTRAN are
encoded, let's make sure we fully support both as per 3GPP TS 31.102
Release 17. As part of this, switch to a sorted list of access technologies,
in order to have a defined order. This makes comparing in unit tests
much easier. However, it also means that we need to sort the set
when printing the list of AcT in pySim-read to generate deterministic
output.
Change-Id: I398ac2a2527bd11e9c652e49fa46d6ca8d334b88
Without this the diff between expected and actual output is truncated
and one instead reads the following output:
Diff is 844 characters long. Set self.maxDiff to None to see it.
We actually want to see the full diff to see what's not matching.
Change-Id: I6e89705061454191b6db1255de7fe549ad720800
When we initialize the reader, we currently tell only which type of
interface we are using, but we do not print the reader number or the
device path.
Let's extend the messages so that the path is printed. To prevent
problems with integration-tests, let's also add an environment variable
that we can use to detect when pySim runs inside a integration-test.
Related: OS#6210
Change-Id: Ibe296d51885b1ef5f9c9ecaf1d28da52014dcc4b
At the moment we only verify that no exceptions occurred but the output
is not yet verfied.
Related: OS#6094
Change-Id: I3aaa779b5bd8f30936c284a80dbdcb2b0e06985c
We now have pySim-shell and pySim-trace. Let's give pysim-test.sh a more
distinctive name so that it is clear to which program it refers.
Related: OS#6094
Change-Id: I438f63f9580ebd3c7cc78cc5dab13c9937ac6e3a
pySim-trace has no test coverage yet. Let's use a script to run a
GSAMTAP pcacp through it and check that no exceptions are raised.
Related: OS#6094
Change-Id: Icfabfa7c59968021eef0399991bd05b92467d8d2
As pySim.cdma_ruim was not imported by test_files.py, the unit tests
were apparently never executed and hence didn't pass. Let's fix both
of those problems.
Change-Id: Icdf4621eb68d05a4948ae9efeb81a007d48e1bb7
There are some functions / classes which are only needed by the legacy
tools pySim-{read,prog}, bypassing our modern per-file transcoder
classes. Let's move this code to the pySim/legacy sub-directory,
rendering pySim.legacy.* module names.
The long-term goal is to get rid of those and have all code use the
modern pySim/filesystem classes for reading/decoding/encoding/writing
any kind of data on cards.
Change-Id: Ia8cf831929730c48f90679a83d69049475cc5077
Rather than writing one test class with associated method for each
OTA algorithm / test, let's do this in a data-driven way, where new
test cases just have to provide test data, while the code iterates over
it.
Change-Id: I8789a21fa5a4793bdabd468adc9fee3b6e633c25
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 introduces a hierarchy of classes implementing
* ETS TS 102 225 (general command structure)
* 3GPP TS 31.115 (dialects for SMS-PP)
In this initial patch only the SMS "dialect" is supported,
but it is foreseen that USSD/SMSCB/HTTPS dialects can be
added at a later point.
Change-Id: I193ff4712c8503279c017b4b1324f0c3d38b9f84
This introduces a new pySim.apdu module hierarchy, which contains
classes that represent TPDU/APDUs as exchanged between
SIM/UICC/USIM/ISIM card and UE.
It contains instruction level decoders for SELECT, READ BINARY and
friends, and then uses the pySim.filesystem.Runtime{Lchan,State} classes
to keep track of the currently selected EF/DF/ADF for each logical
channel, and uses the file-specific decoder classes of pySim to decode
the actual file content that is being read or written.
This provides a much more meaningful decode of protocol traces than
wireshark will ever be able to give us.
Furthermore, there's the new pySim.apdu_source set of classes which
provides "input plugins" for obtaining APDU traces in a variety of
formats. So far, GSMTAP UDP live capture and pyshark based RSPRO
live and pcap file reading are imlpemented.
Change-Id: I862d93163d495a294364168f7818641e47b18c0a
Closes: OS#5126
The DataObject is some weird / rarely used different code than the
normal TLV encoder/decoder. It has apparently so far only been used
for decoding, without testing the encoding side, resulting in related
bugs.
Let's fix those that I encountered today, and add a test case.
Change-Id: I31370066f43c22fc3ce9e2b9ee75986a652f6fc4
We have a number of integers with variable-length encoding, so
add a Construct for this. Naming inspired by GreedyBytes.
Related to https://github.com/construct/construct/issues/962
Change-Id: Ic6049b74ea3705fda24855f34b4a1d5f2c9327f7
when encoding the AcT value bit 11 is correctly set
when NG-RAN is present in the string representation,
however the decoding of bit 11 was missing.
Adds tests for the decoder as well.
Change-Id: I910df28c4c59ec94cce9603377786325f6d8c1a3
When the Access Technology Identifier encoder sets the bits for E-UTRAN
it does not respect that bit "100" is also a valid bit combination that
encodes E-UTRAN WB-S1 and E-UTRAN NB-S1. Lets encode this bit
combination if the user is just specifying "E-UTRAN" without further
spefication of WB or NB.
The decoder only looks at bit 14 and decodes "1xx" always to "E-UTRAN".
This is not specific enough. Lets make sure that the decoder is
complementary to the encoder.
Change-Id: Ibfe8883a05f9ad6988d8e212cb9a598229954296
Related: OS#4963
The function dec_xplmn_w_act(), which is also used by
format_xplmn_w_act() is using integer numbers as MCC/MNC representation.
This causes various problems since the information about leading zeros
gets lost.
Change-Id: I57f7dff80f48071ef9a3732ae1088882b127a6d4
The dec_plmn function takes an hexstring and returns the decoded MCC and
MNC as integer values. The result is then used by the json encoder in
EF_PLMNsel, which means the json output will contrary to the input, use
integer values instead of strings.
This is not correct since there may be leading zeros (e.g. mnc 01 and
001 both exist are different) which must be retained in order to know
the correct length of the MNC.
Related: OS#4963
Change-Id: I393e04836814d992d2a6d0a4e4e01850976d6e81
The encoding of EF.MSISDN is a bit unstrutured. The encoder function
does not return a valid result since it lacks the parameters
Capability/Configuration2 Record Identifier and Extension5 Record
Identifier, which are mandatory but can be set to 0xFF. Also the
encoder gets its input from pySim-shell, so it should have some
more input validation, especially when the user encodes an empty
string. The encoder and decoder function also do not have unit-tests.
Since the encoder now adds the missing two bytes by isself this does
not have to be done manually anymore, so cards.py needs to be
re-aligned.
For pySim-shell.py the encoder is used from ts_51_011.py. Unfortunately
it is used wrongly there. The optional Alpha Identifier is required
here as well.
Related: OS#4963
Change-Id: Iee5369b3e3ba7fa1155facc8fa824bc60e33b55b
The folder pysim-testdata already contains testdata that can also be
used as examples. The .example files are from a time where the testdata
was not kept inside the repository. Since we decided to keep the test
data in the repository as well those file are redundant.
Change-Id: Iee34cad74b50755e1007506f909da9766fa8412e
The bug that was attempted to be fixed in [1] actually was in the
encoding API - pySim.utils.enc_plmn(). According to 3GPP TS 31.102,
which points to TS 24.008, the three-digit (E)HPLMN shall be encoded
as shown below (ASCII-art interpretation):
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| MCC Digit 2 | MCC Digit 1 |
+---+---+---+---+---+---+---+---+
| MNC Digit 3 | MCC Digit 3 |
+---+---+---+---+---+---+---+---+
| MNC Digit 2 | MNC Digit 1 |
+---+---+---+---+---+---+---+---+
while pySim.utils.enc_plmn() would produce the following:
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| MCC Digit 2 | MCC Digit 1 |
+---+---+---+---+---+---+---+---+
| MNC Digit 1 | MCC Digit 3 |
+---+---+---+---+---+---+---+---+
| MNC Digit 3 | MNC Digit 2 |
+---+---+---+---+---+---+---+---+
Initially the _decoding_ API was correct, but then got changed in
[1] to follow buggy pySim's encoding API. As a result, a (E)HPLMN
programmed with pySim-prog.py would look correct if verified by
pySim-read.py, but the actual file content would be wrong.
This situation shows that our 'program-read-match' build verification
approach alone is insignificant. The lack of unit test coverage,
at least for the core parts of the project, makes it possible to have
symmetrical bugs in both encoding and decoding API parts unnoticed.
This problem was found while trying to enable dead unit tests in [3].
Change [1] that introduced a symmetrical bug is reverted in [2].
Change-Id: Ic7612502e1bb0d280133dabbcb5cb146fc6997e5
Related: [1] I799469206f87e930d8888367890babcb8ebe23a9
Related: [2] If6bf5383988ad442e275efc7c5a159327d104879
Related: [3] I4d4facfabc75187acd5238ff4d0f26022bd58f82
