Project

General

Profile

Feature #2562

KI with varying lengths

Added by neels 11 days ago. Updated 10 days ago.

Status:
New
Priority:
Normal
Assignee:
Target version:
-
Start date:
10/09/2017
Due date:
% Done:

0%


Description

According to openbsc/gsm_data_shared.h, there is an

#define A38_XOR_MIN_KEY_LEN     12
#define A38_XOR_MAX_KEY_LEN     16

but there is no concept of varying key lengths in osmo-hlr. For 2G, there is the 128bit KI and that's it:
In struct osmo_sub_auth_data we have only the uint8_t ki[OSMO_A5_MAX_KEY_LEN_BYTES] in .gsm.

In OsmoNITB, we allow to pass a shorter KI for the VTY command

subscriber imsi 123456 a3a8 xor 123456789abc123456789abc

and in the old struct gsm_auth_info we store an a3a8_ki_len, which gets populated from the binary length found in the db.

Adding VTY commands to osmo-hlr, the question is whether we should simply require a KI of 128bit and be done with it.

Otherwise we need to adjust libosmocore's struct osmo_sub_auth_data to indicate a ki_len.
And should probably add regression tests with varying KI lengths for XOR.

History

#1 Updated by neels 11 days ago

  • Status changed from New to Feedback
  • Assignee set to laforge

#2 Updated by neels 11 days ago

  • Description updated (diff)

#3 Updated by laforge 11 days ago

On Mon, Oct 09, 2017 at 03:23:21PM +0000, neels [REDMINE] wrote:

According to openbsc/gsm_data_shared.h, there is an

> #define A38_XOR_MIN_KEY_LEN     12
> #define A38_XOR_MAX_KEY_LEN     16

The question is: where does this come from?  Is there some spec referefence
for this?  In general my gut feeling is we don't have to care.

#4 Updated by laforge 10 days ago

  • Status changed from Feedback to New
  • Assignee changed from laforge to neels

Also available in: Atom PDF