Attention is currently required from: Hoernchen, dexter, laforge.
Hello Jenkins Builder, dexter, laforge,
I'd like you to reexamine a change. Please visit
https://gerrit.osmocom.org/c/pysim/+/43172?usp=email
to look at the new patch set (#2).
The following approvals got outdated and were removed: Code-Review+1 by laforge, Code-Review+2 by dexter, Verified+1 by Jenkins Builder, Verified+1 by dexter
The change is no longer submittable: Code-Review and Verified are unsatisfied now.
Change subject: GP: LOAD/STORE DATA chunk size from SCP overhead ......................................................................
GP: LOAD/STORE DATA chunk size from SCP overhead
SCP.overhead was so far set at construction time (SCP02: 8, SCP03: s_mode), so the C-MAC length only. Unfortunately sec lvl >= 3 pads the data field to the cipher block size before encryption, so the real worst-case overhead is larger, scc.max_cmd_len (255 - overhead) was too big, and ADF_SD.load() used a hardcoded chunk_len=240.
Real world issue with a 286 byte CAP + SCP02 + sec lvl 3: - 240-byte LOAD block is padded to 248, - encrypted - gets 8 byte C-MAC appended -> Lc = 256 That dies with a weird "ValueError: bytes must be in range(0, 256)". The only "fix" for that was to downgrade the seclevel.
STORE DATA has the same overflow with large max_cmd_len (247 + padding + MAC = 256 as well).
Therefore the overhead must be properly calculated from the sec level.
While at it adjust the error in case I missed something to get a more useful ValueError.
Change-Id: Ic208f3959a38896f64fb6ccefb24cc360a3ac3a2 --- M pySim/global_platform/__init__.py M pySim/global_platform/scp.py M tests/unittests/test_globalplatform.py 3 files changed, 224 insertions(+), 12 deletions(-)
git pull ssh://gerrit.osmocom.org:29418/pysim refs/changes/72/43172/2