Implement get_values_from_pes(), the reverse direction of apply_val():
read back and return values from a ProfileElementSequence. Implement for
all ConfigurableParameter subclasses.
Future: SdKey.get_values_from_pes() is reading pe.decoded[], which works
fine, but I07dfc378705eba1318e9e8652796cbde106c6a52 will change this
implementation to use the higher level ProfileElementSD members.
Implementation detail:
Implement get_values_from_pes() as classmethod that returns a generator.
Subclasses should yield all occurences of their parameter in a given
PES.
For example, the ICCID can appear in multiple places.
Iccid.get_values_from_pes() yields all of the individual values. A set()
of the results quickly tells whether the PES is consistent.
Rationales for reading back values:
This allows auditing an eSIM profile, particularly for producing an
output.csv from a batch personalization (that generated lots of random
key material which now needs to be fed to an HLR...).
Reading back from a binary result is more reliable than storing the
values that were fed into a personalization.
By auditing final DER results with this code, I discovered:
- "oh, there already was some key material in my UPP template."
- "all IMSIs ended up the same, forgot to set up the parameter."
- the SdKey.apply() implementations currently don't work, see
I07dfc378705eba1318e9e8652796cbde106c6a52 for a fix.
Change-Id: I234fc4317f0bdc1a486f0cee4fa432c1dce9b463
Implement pySim.esim.saip.personalization.BatchPersonalization,
generating N eSIM profiles from a preset configuration.
Batch parameters can be fed by a constant, incrementing, random or from
CSV rows: add pySim.esim.saip.param_source.* classes to feed such input
to each of the BatchPersonalization's ConfigurableParameter instances.
Related: SYS#6768
Change-Id: I497c60c101ea0eea980e8b1a4b1f36c0eda39002
Discover all non-abstract subclasses of ConfigurableParameter in
ConfigurableParameter.get_all_implementations().
To be able to automatically discover all practically useful
ConfigurableParameter subclasses, introduce the is_abstract flag.
ConfigurableParameter itself sets is_abstract = True, by default
"hiding" subclasses. As soon as a subclass sets is_abstract = False, it
becomes "public". It depends on the calling code to actually implement
that decision -- this flag enables calling code to do so sanely.
For example, the BinaryParam superclass keeps is_abstract = True,
because per se it isn't capable of doing anything. The fully useful K
and Opc subclasses set is_abstract = False.
Implementation choice: I first tried to query an implicit abstract
status via abc / @abstractmethod ways, but it did not match well. A
subclass has no good implicit indicator, we need a flag instead. For
example, a superclass may provide an apply_val() implementation and
hence appear as non-abstract, but it is still not usable because a
specific 'key' member is still None, which various subclasses set.
Related: SYS#6768
Change-Id: I4970657294130b6b65d50ff19ffbb9ebab3be609
For all ConfigurableParameter subclasses, set a default_value.
This is useful for user interaction, to prefill an input field that
indicates a valid input to modify to taste.
Related: SYS#6768
Change-Id: I2672fedcbc32cb7a6cb0c233a4a22112bd9aae03
These names better match what humans expect to read, for example "PIN1"
instead of "Pin1".
(We still fall back to the __class__.__name__ if a subclass omits a
specific name, see the ConfigurableParameter init.)
Change-Id: I31f390d634e58c384589c50a33ca45d6f86d4e10
Refactor SdKey (and subclasses) to the new ConfigurableParameter
implementation style, keeping the same implementation.
But duly note that this implementation does not work!
It correctly patches pe.decoded[], but that gets overridden by
ProfileElementSD._pre_encode().
For a fix, see I07dfc378705eba1318e9e8652796cbde106c6a52.
Change-Id: I427ea851bfa28b2b045e70a19a9e35d361f0d393
Refactor AlgorithmID, K, Opc to the new ConfigurableParameter
implementation style.
K and Opc use a common abstract BinaryParam.
Note from the future: AlgorithmID so far takes "raw" int values, but
will turn to be an "enum" parameter with predefined meaningful strings
in I71c2ec1b753c66cb577436944634f32792353240
Change-Id: I6296fdcfd5d2ed313c4aade57ff43cc362375848
Implement abstract DecimalHexParam, and use it to refactor Puk1 and Puk2
to the new ConfigurableParameter implementation style.
DecimalHexParam will also be used for Pin and Adm soon.
Change-Id: I271e6c030c890778ab7af9ab3bc7997e22018f6a
Main points/rationales of the refactoring, details below:
1) common validation implementation
2) offer classmethods
The new features are optional, and will be heavily used by batch
personalization patches coming soon.
Implement Iccid and Imsi to use the new way, with a common abstract
DecimalParam implementation.
So far leave the other parameter classes working as they always did, to
follow suit in subsequent commits.
Details:
1) common validation implementation:
There are very common validation steps in the various parameter
implementations. It is more convenient and much more readable to
implement those once and set simple validation parameters per subclass.
So there now is a validate_val() classmethod, which subclasses can use
as-is to apply the validation parameters -- or subclasses can override
their cls.validate_val() for specialized validation.
(Those subclasses that this patch doesn't touch still override the
self.validate() instance method. Hence they still work as before this
patch, but don't use the new common features yet.)
2) offer stateless classmethods:
It is useful for...
- batch processing of multiple profiles (in upcoming patches) and
- user input validation
to be able to have classmethods that do what self.validate() and
self.apply() do, but do not modify any self.* members.
So far the paradigm was to create a class instance to keep state about
the value. This remains available, but in addition we make available the
paradigm of a singleton that is stateless (the classmethods).
Using self.validate() and self.apply() still work the same as before
this patch, i.e. via self.input_value and self.value -- but in addition,
there are now classmethods that don't touch self.* members.
Related: SYS#6768
Change-Id: I6522be4c463e34897ca9bff2309b3706a88b3ce8
Drop the ClassVarMeta/metaclass/ABCMeta stuff -- it doesn't seem to
serve any purpose that is not similarly achieved with plain python
inheritance.
Upcoming patches will use normal inheritance a lot more.
Note that most use of the ClassVarMeta was in the SdKey subclasses, and
that these currently don't actually work. See the fix in patch
I07dfc378705eba1318e9e8652796cbde106c6a52 .
name: set a default name from the python class, as ClassVarMeta did.
Also allow setting an explicit string as name instead, per subclass
implementation (see I31f390d634e58c384589c50a33ca45d6f86d4e10).
Related: SYS#6768
Change-Id: I60ea8fd11fb438ec90ddb08b17b658cbb789c051
The PE-Application object is used to provision JAVA-card applications
into an eUICC during profile installation. Let's extend the SAIP-tool
so that we are able to add, remove and inspect applications.
Change-Id: I41db96f2f0ccc29c1725a92215ce6b17d87b76ce
The application profile element has no ProfileElement class yet, so
let's create a ProfileElementApplication class and move the existing
extract-apps code into a method of ProfileElementApplication.
Change-Id: Iaa43036d388fbf1714c53cab1fc21092c4667a21
pre-empt this from coming up in patch
I60ea8fd11fb438ec90ddb08b17b658cbb789c051:
E1135: Value 'self.permitted_len' doesn't support membership test (unsupported-membership-test) pickermitted_len
Change-Id: I0343f8dbbffefb4237a1cb4dd40b576f16111073
In case the fileDescriptor of EF.IMSI is purely template based and only
the file content is given in the actual profile, we must pass a template
reference to the File() constructor before we can read the IMSI.
This fixes the following exception for some profiles:
ValueError: File(ef-imsi): No fileDescriptor found in tuple, and none set by template before
Change-Id: I14157a7b62ccd9b5b42de9b8060f2ebc5f91ebb3
So far we mainly created File() instances when parsing existing
profiles. However, sometimes we want to programmatically create Files
and we should offer a convenience helper to do so, rather than asking
API users to worry about low-level details.
Change-Id: I0817819af40f3d0dc0c3d2b91039c5748dd31ee2
The point of the SAIP template mechanism is to reduce the size of the
encoded profile. Therefore, our encoder in the to_fileDescriptor()
method should suppress generating attributes if their value is identical
to that of the template (if any).
Change-Id: I337ee6c7e882ec711bece17b7a0def9da36b0ad7
The encoding of the access rule reference is different in FileTemplate
vs File, let's make sure we properly convert it when instantiating a
File from a FileTemplate.
Change-Id: Ibb8afb85cc0006bc5c59230ebf28b2c0c1a8a8ed
If the API user modifies the size of the body, we need to check if we
need to re-compute the file_size attribute which is later encoded into
the fileDescriptor. The size obviously must be large enough to fit the
body. Let's do this implicitly by introducing a setter for File.body
Change-Id: I1a908504b845b7c90f31294faf2a6e988bdd8049
ProfileElements.insert_after_pe() is a convenience method to insert
a new PE after an existing one in the sequence. This is a frequent
task as there are strict ordering requirements in the SAIP format.
Change-Id: I4424926127b4867931c2157e9340bacd2682ff0c
When generating the file content (body), we need to proceed in the
following order:
1a) If FCP contains fillPattern/repeatPattern, compute file content from those
1b) If FCP doesn't contain fillPattern/repeatPattern but template
exists, compute file content from template
2) Apply any fillFileConten / fillFileOffset from the SAIP File on top
of the above
Change-Id: I822bb5fbec11a3be35910a496af7168458fd949c
Closes: OS#6642
If we know the efFileSize and record_len, but Fcp doesn't contain
the number of records, we can simply compute it.
Change-Id: I0cc8e7241e37ee23df00c2622422904e7ccdca77
There's a second flag hidden in the TS 102 222 "Special File
Information"; let's parse + re-encode it properly.
Change-Id: I7644d265f746c662b64f7156b3be08a01e3a97aa
Related: OS#6643
So far we only thought of default filling coming from a template.
However, filling can happen from the Fcp, and we need to properly parse
and [re-]encode that information.
Change-Id: Iff339cbe841112a01c9c617f43b0e69df2521b51
Related: OS#6643
When constructing a ProfileElmentGFM from scratch, initialize the
decoded['fileManagementCMD'], as it is a mandatory member during
ASN.1 encode.
Change-Id: Iaae99348d36b7f0c739daf039d6ea2305b7ca9db
The choice member is called df-5gprose but the header is called
'df-5g-prose-header' (note the '-' between '5g' and 'prose'). WTF.
Change-Id: I86004ac2e18a187c26c5e470344908512d21fb9e
Sometimes the struct member is called like df-telecom, but in other
cases it's called df-df-saip with a double 'df' in front. That makes
no sense, but we have to deal with it from our constructors...
Change-Id: If5e670441f03a47fa34e97a326909b24927c12f7
We're creating a 'pyosmocom' pypi module which contains a number of core
Osmocom libraries / interfaces that are not specific to SIM card stuff
contained here.
The main modules moved in this initial step are pySim.tlv, pySim.utils
and pySim.construct. utils is split, not all of the contents is
unrelated to SIM Cards. The other two are moved completely.
Change-Id: I4b63e45bcb0c9ba2424dacf85e0222aee735f411
With this change, the ProfileElementSequence object will maintain a
representation of the filesystem hierarchy of the eSIM profile. Every
file that is added by a ProfileElement will add a FsNode into that tree,
and each FsNode will point to the File object for the respective file.
This allows us to find files by their path, as well as add files by
path.
Change-Id: I2caadc24b1087855f23f3c57cdf8dabbf81757c0
The self.files member is a dict. Hence we should use those dict
keys when [re]building the decoded dict. The previous code ignored
it and re-constructed the key from File.pe_name - but that's not
always identical.
Change-Id: I0e6c97721fb1cfc6b5c21595d85bd374d485b573
Store a back-reference to the PE-Sequence in the PE object; this is
neccessary for some upcoming patches, e.g. to determine the position in
the sequence, access the global filesystem hierarchy, etc.
Change-Id: I24b692e47e4dd0afb5a17b04d5e0251dded3d611
Having AKA specific code in the generic ProfileElement base class dated
back to when we didn't have a ProfileElementAKA subclass.
Change-Id: Icd332183758b8ef20a77507b728f5e455698def0
When populating a File from a FileTemplate, let's make sure we
* correctly treat the maximum file size for BER-TLV files
* respect the default value pattern / repeat pattern
* respect the high_update flag.
Change-Id: I3ba092e0893f53a18264dff5fa37b12ccd9bd47e
So far the prefix_match() required a string argument; let's also
permit another OID object to be passed; we internally convert that
to string.
Change-Id: I0feb7782d1813cc46ec78f170eb0fce804aebe3a
The SAIP specification is very weird in a way that it treats the DF and
EF descriptions as some kind of flat structure without describing the
hierarchy. So when creating a DF, sometimes it should be created below
the current DF, and sometimes it should be adjacent next to the current
DF.
Let's introduce
* a 'ppath' property of FileTemplate to indicate if a file is anything
but a direct sibling of the 'base DF' of the PE
* an 'extends' property of ProfileTemplate to indicate that a given
template does not have its own 'base DF', but that its contents merely
extends that of another ProfileTemplate
* a 'parent' property of ProfileTemplate to indicate a parent
ProfileTemplate below whose 'base DF' our files should be placed.
Change-Id: Ieab4835cd21008b289713784c0eb7170af2ccfb9
This method can be used to expand the default value pattern of the
file system template for the file to the specified (record, file) length.
Change-Id: Id3eb16910c0bdfa572294e14ca1cd44ca95ca69f
