HSS only supports OP value, not card-individual OPc

[laf0rge]

The current HSS (at least on the web interface) offers to enter the following fields for each card:

• K
• OP
• AMF

This doesn't match reality and/or the specs, as far as I can tell.
3GPP USIM either have

• card-individual K + card-individual OPC value
• card-individual K + "global" OP value
  ** global means, OP is the same for all cards, or at the very least for all cards of the same production batch

nextepc HSS appears to implement something like a mix of the two: No card-individual OPc, but a card-individual OP. I cannot find any spec reference of this combination.

Please let me know if I misunderstand something, and my apologies for that case.

[acetcom]

As I know, OPc can be derived from K and OP value like the src/hss/milenage.c

void milenage_opc(const c_uint8_t *k, const c_uint8_t *op,  c_uint8_t *opc)
{
    int i;

    aes_128_encrypt_block(k,  op, opc);

    for (i = 0; i < 16; i++)
    {
        opc[i] ^= op[i];
    }
}

I have no experience how EPC is deployed. So I'm not sure which value is good to store database.

I've assumed it as follows.

1. Operator order USIM with global OP, K, and AMF
2. USIM manufacturer provide the chip with individual OPc, K, and AMF
   (Individual OPc is derived from OP and K).
3. Operator add new subscriber with global OP, K, and AMF.

And also, there is one more operator in this system. So, I've stored OP in the Subscriber database.

At this point, I don't know whether the above scenario is right or not. If operator also want to use the individual OPc that is not derived from global OP, I'll change OP to OPc field in Web User Interface.

[laf0rge]

Both scenarios exist. It is up to the agreement between SIM card manufacturer and operator whether they use global OP or card-individual OPC. In OsmoHLR, we have prepared the database for both variants. I know it adds complexity, but it's unfortunately the only solution to cover both common cases.

For my immediate testing, I've reprogrammed my card to use global OP instead of OPc and authentication via USIM-UE-ENB-MME-HSS is now working with nextepc. So I can make progress right now, but I guess sooner or later somebody will have this issue and not be able to reprogram the card[s].

Regarding your assumption that the card would always contain an OPc: This is unfortunately not correct. We know of at least one widely-used CardOS / USIM application which actually stores the global OP on each card in case of "global OP" case, and only a card-individual OPc in case of card-individual OPc.

[anoveth]

Sukchan, we should cover both scenarios, regarding pratical use-cases at least. It seems that real USIMs might be provided not only with 'OP' + 'K', but also with 'OPc' + 'K' although 'OPc' is derived from 'OP' and 'K' by the 'Milenage' algorithm framework. And please refer to the following about "OPc computed off the USIM":

(From ETSI TS 135 206)
5.1 OPC computed on or off the USIM?

Recall that OP is an Operator Variant Algorithm Configuration Field. It is expected that each operator will define a value of OP which will then be used for all its subscribers. (It is up to operators to decide how to manage OP. The value of OP used for new batches of USIMs could be changed occasionally; or perhaps a different value could be given to each different USIM supplier. OP could even be given a different value for every subscriber if desired, but that is not really the intention.)
It will be seen in section 4.1 that OPC is computed from OP and K, and that it is only OPC, not OP, that is ever used in subsequent computations. This gives two alternative options for implementation of the algorithms on the USIM:

(a) OPC computed off the USIM: OPC is computed as part of the USIM prepersonalisation process, and OPC is stored on the USIM. OP itself is not stored on the USIM.
(b) OPC computed on the USIM: OP is stored on the USIM (it may be considered as a hard-coded part of the algorithm if preferred). OPC is recomputed each time the algorithms are called.

The SAGE Task Force recommends that OPC be computed off the USIM if possible, since this gives the following benefits:

• The complexity of the algorithms run on the USIM is reduced.
• It is more likely that OP can be kept secret. (If OP is stored on the USIM, it only takes one USIM to be reverse engineered for OP to be discovered and published. But it should be difficult for someone who has discovered even a large number of (OPC, K) pairs to deduce OP. That means that the OPC associated with any other value of K will be unknown, which may make it harder to mount some kinds of cryptanalytic and forgery attacks. The algorithms are designed to be secure whether or not OP is known to the attacker, but a secret OP is one more hurdle in the attacker's path.)

[acetcom]

It's good discussion. Let me add OPc field in nextepc database.

On the HSS aspect,

• If there is OPc value in the database, HSS will use it directly without calculation at first.
• If there is no OPc value, HSS will try to find OP value in the database, and if there is OP value, HSS will derive OPc value from K and OP value.

And also, I will update WebUI for supporting these two value.

Thanks!

[acetcom]

I've updated WebUI and HSS for supporting OPc in r0.2 branch.

Even though database stores both OP and OPc, End-User enter only one of OP and OPc in the WebUI.

Thanks!