Attention is currently required from: laforge.
10 comments:
File docs/smpp-ota-tool.rst:
Patch Set #1, Line 5: cards
an eUICC must not be a card, in fact most often it is not. […]
I think SIM/UICC/eUICC should cover all variations. (As far as I know classic SIMs were already able to receive OTA-SMS messages)
SMPP
server
"... SMPP server (such as a production SMSC of a live cellular network) as well." […]
Done
it's not "a set" but "sets of keys".. […]
Done
we have many more instances of "card" in the document, it seems. […]
Done
Patch Set #1, Line 26: The KIK is not used in the scope of SCP80.
oh, are you sure? That means you cannot deploy new SCP80 (or other) keys via SCP80? I would have as […]
I have asked myself the same question but I could not find any reference to KIK in ETSI TS 102 225
This lead me to the assumption that KIK is not available in SCP80. When I look at Table 1. There is only "KIc" and "KID", not "KIK" or anything. We also only have the sections "Coding of KIc" and "Coding of KID".
But I have had closer look at this again now: ETSI TS 102 226, section 8.2.1.5 hints towards that the KIK (DEK) is implicitly selected. KIc and KID must be the same numbers anyway (mixing keys from different keysets is forbidden, but SCP80 would technically allow it). The spec says: "The transport security keys (i.e. KIc/KID) used to secure the Response Packet shall be the same as the ones of the
Command Packet containing the PUT KEY command.", so when KIc/KID is 1, then KIK is also 1. and so on.
So, I think we should write this paragraph a bit differently...
(I still have problems to understand to which layer the KIK actually belongs to. To me it seems that it is more or less something that is specific to put_key. If this is true it should not be mentioned in any of those specs and only be discussed in the global platform spec where put_key is specified.)
Patch Set #1, Line 28: programmed into the issuer security domain (ISD)
the keyset doesn't have to be in the ISD. […]
Done
Patch Set #1, Line 84: A0A40000027F20
might be worth using formatting instructions to use monospaced font for all APDUs or other hex-strin […]
Done
Patch Set #1, Line 86: is received by the SIM RFM application and then executed. This method poses some limitations that have to be taken into
might be worth stating that he SIM RFM application is "on the card"
Done
To prevent this, we may include a replay protection counter within the message. In this case, the MSL indicates that a
replay protection counter is not required. However, to extended the security of our messages, we may chose to use a
counter anyway. In the following example, we will encode a counter value of 100. We will instruct the card to make sure
that the value we send is higher than the counter value that is currently stored in the card.
it might be worth mentioning at some earlier point that the MSL of the card may be different for dif […]
Done
Patch Set #1, Line 162: overlap
"... it will not wrap on overflow ...
Done
To view, visit change 42237. To unsubscribe, or for help writing mail filters, visit settings.