aboutsummaryrefslogtreecommitdiffstats
path: root/include/osmocom/crypt/auth.h
AgeCommit message (Collapse)AuthorFilesLines
2023-06-05struct osmo_sub_auth_data: remove OSMO_DEPRECATED_OUTSIDEVadim Yanitskiy1-1/+1
I was the one who suggested adding this attribute during code review, and now, having realized it was a bad idea, I am removing it. The problem is that this attribute spams compilation logs of projects including file <osmocom/crypt/auth.h>, even if the deprecated struct is not used directly at all. Change-Id: Ia5d365206207872d5d3fdd4ae40273eab909fb33 Fixes: 08450c9e "libosmogsm: Support authentication with 256-bit K and/or OP/OPc"
2023-06-02libosmogsm: Add support for TUAK authentication algorithmHarald Welte1-0/+1
The TUAK algorithm is specified in 3GPP TS 35.231, 232 and 233 and intended as an alternative to MILENAGE. It's based around the cryptographic function of KeccakP1600, which is part of SHA-3. This patch adds support for TUAK to the libosmogsm authentication core API via 'struct osmo_auth_impl'. Unit tests covering the test cases from the 3GPP specification are added (and are all passing). Change-Id: Ib905b8d8bdf248e8299bf50666ee1bca8298433d
2023-06-02libosmogsm: Factor out the C2 derivation functionHarald Welte1-0/+1
3GPP specifies the C2 derivation function (generating GSM SRES from UMTS XRES) independent of the MILENAGE algorithm. So instead of open-coding it in milenage.c:gsm_milenage(), let's create a separate public function osmo_auth_c2() similar to the already-existing osmo_auth_c3() function. gsm_milenage() can then simply use that function. Change-Id: I0e7cd55f5578f891cb6cc1b0442920ba5beddae4
2023-06-02libosmogsm: Allow auth API caller to specify RES lengthHarald Welte1-1/+1
There are 3G algorithms which support different lengths of RES values (4, 8, 16 byte). For MILENAGE, we never really had to bother, as the 4-byte RES is simply the first 4 bytes of the 8-byte RES. However, for TUAK, the expected RES length is an input parameter to the Keccak crypto functions, so the result of all parameters (including CK, IK, ...) will be completely different for RES length 4 than RES length 8. So let's permit the caller of the osmocom auth API to specify the requested RES length via the osmo_auth_vector.res_len parameter. For backwards compatibility of callers of the old osmo_auth_gen_vec/ osmo_auth_gen_vec_auts API: Always force the res_len to 8 in this case, which was the hard-coded length before this patch. Change-Id: Ic662843fbe8b5c58e4af39ea630ad5ac13fd6bef
2023-06-02libosmogsm: Support authentication with 256-bit K and/or OP/OPcHarald Welte1-6/+40
3GPP TS 33.102 Section 6.3.7 states that K can be 128 or 256 bits, while our 'struct osmo_sub_auth_data' had a fixed-size 128bit field. This means we cannot use our auth_core for algorithms with larger key sizes, such as TUAK. Let's introduce osmo_sub_auth_data2 for larger (and variable) sized K and OP[c]. K and OP[c] can even have different sizes in TUAK, where OP[c] is always 256bit, but K can be 128 or 256 bits. So we need separate length fields for K and OP[c]. I'm adding backwards-compatibility API wrappers, so old applications just continue to work as they always did. However, I'm not adding compatibility wrappers for the plug-in API that can be used to register additional authentication implementations at runtime. We don't know of any user of that API outside of libosmocore, so the function signatures of the 'struct osmo_auth_impl' are modified in an incompatible way. Change-Id: Ie775fedba4a3fa12314c0f7c8a369662ef6a40df
2023-02-22Rename OSMO_AUTH_ALG_XOR to OSMO_AUTH_ALG_XOR_3GHarald Welte1-1/+4
Let's disambiguate. Our existing OSMO_AUTH_ALG_XOR was always only the XOR-3G algorithm. Now that we recently introduced XOR-2G, let's rename (with backwards compatibility #define). Change-Id: I446e54d0ddf4a18c46ee022b1249af73552e3ce1
2023-02-21Implement the XOR-2G authentication algorithmHarald Welte1-0/+1
We've so far only been supporting XOR-3G algorithm as specified in TS 34.108 (in both 3G and 2G-derivation mode). However, XOR-3G used for 2G auth is different from the XOR-2G algorithm as defined in Annex A of TS 51.010-1. Let's add support for that one, too. Change-Id: I0ee0565382c1e4515d44ff9b1752685c0a66ae39
2018-12-20Use define for key buffersMax1-3/+3
Add corresponding spec. references and comments where appropriate. Change-Id: If5e2aad86eaecd8eada667b3488ba415d81c6312
2017-12-18add osmo_auth_c3() (separate from gsm_milenage())Neels Hofmeyr1-0/+2
To send a Ciphering Mode Command, we may need to derive a Kc from UMTS AKA tokens. gsm_milenage() derives Kc from 3G tokens, but also derives an SRES. For SRES, it requires an OPC, which may need to be derived from OP first. All we need is a Kc, so we could feed a zero OPC ... but to simplify the function call for cases where just a Kc is required, separate the c3 function out from gsm_milenage(), as osmo_auth_c3(). Obviously call osmo_auth_c3() from gsm_milenage() (meaning that osmo-hlr's 55.205 derived auc tests still cover exactly that implementation). Prepares: If04e405426c55a81341747a9b450a69188525d5c (osmo-msc) Related: OS#2745 Change-Id: I85a1d6ae95ad9e5ce9524ef7fc06414848afc2aa
2017-10-17[doc] Provide proper name for 'auth' groupHarald Welte1-1/+1
Change-Id: I5fb1c34475ea9db36c2ec5cddc988074a72a35f7
2017-10-09auth: add OSMO_MILENAGE_IND_BITLEN_MAXNeels Hofmeyr1-0/+1
Will be used by OsmoHLR to validate VTY and CTRL input. Change-Id: Ic39f3404d1a49ffd06070aa9897b36f219eacf4d
2017-10-09auth: add value_strings for osmo_sub_auth_type, comment on osmo_auth_alg_name()Neels Hofmeyr1-1/+7
Add osmo_sub_auth_type_names[] and osmo_sub_auth_type_name(). Also add a hint to enum osmo_auth_algo's API doc that osmo_auth_alg_name() already exists (it is defined further below). Change-Id: I652a929bcd11c694d86812fb03d0a1cbd985efda
2017-08-30Add define for supported a5 key length limitMax1-1/+3
Change-Id: I8ed0f1dbc31aaff22a685ceb3bd2f8db4d2f34fd
2017-08-29umts aka: add sqn_ms out-param, print SQN.MS in osmo-auc-genNeels Hofmeyr1-0/+1
When doing UMTS AKA with AUTS, it can be interesting to know the SQN.MS that was encoded in the AUTS. The only way to know this is to provide it as a separate out-parameter from milenage_gen_vec_auts(), because the SQN.MS from AUTS stored in umts.sqn is immediately modified non-trivially by milenage_gen_vec(). Add sqn_ms to struct osmo_sub_auth_data to retain SQN.MS even after a vector was generated. Use this to print out SQN.MS for 'osmo-auc-gen -3 -A'. Adjust test suite expectations. Related: OS#2464 Change-Id: I9fc05bbf169d06716f40b995154fd42a3f91bef3
2017-08-29cosmetic: umts aka: tweak comments for sqn and indNeels Hofmeyr1-2/+2
Clearly indicate that 'sqn' is an in *and* out-parameter. Clarify the effect of 'ind'. Change-Id: Ia40cd4ddf35f4fbe895b45b8ea59378f5ce9eb1f
2017-06-23doxygen: unify use of \file across the boardNeels Hofmeyr1-3/+1
Considering the various styles and implications found in the sources, edit scores of files to follow the same API doc guidelines around the doxygen grouping and the \file tag. Many files now show a short description in the generated API doc that was so far only available as C comment. The guidelines and reasoning behind it is documented at https://osmocom.org/projects/cellular-infrastructure/wiki/Guidelines_for_API_documentation In some instances, remove file comments and add to the corresponding group instead, to be shared among several files (e.g. bitvec). Change-Id: Ifa70e77e90462b5eb2b0457c70fd25275910c72b
2017-06-23doxygen: enable AUTOBRIEF, drop \briefNeels Hofmeyr1-6/+6
Especially for short descriptions, it is annoying to have to type \brief for every single API doc. Drop all \brief and enable the AUTOBRIEF feature of doxygen, which always takes the first sentence of an API doc as the brief description. Change-Id: I11a8a821b065a128108641a2a63fb5a2b1916e87
2017-03-15osmo_auth_gen_vec: UMTS auth: fix SQN as SEQ || INDNeels Hofmeyr1-0/+2
So far we incremented SQN by 1, which doesn't match the procedures described in 3GPP TS 33.102. An IND (index) denotes a non-significant part of SQN, and the significant SEQ part needs to be incremented. In OsmoHLR we furthermore want to use the "exception" suggested in annex C.3.4, so that each HLR's client has a fixed IND index. In other words, we will not assign IND cyclically, but keep IND unchanged per auth vector consumer. Add 'ind_bitlen' and 'ind' to the osmo_sub_auth_data.u.umts structure and increment SQN accordingly. Add a comment explaining the details. Because 'ind_bitlen' is still passed as zero, the milenage_test does not change its behavior, which is a feature I want to clearly show in this patch. The test will be expanded for the newly implemented SQN scheme in a subsequent patch. Adjust osmo-auc-gen.c to still show the right SQN and SQN.MS -- because it is passing ind_bitlen == 0, osmo-auc-gen can rely on single increments and know SQN.MS is sqn - 1. Note that osmo-auc-gen_test output remains unchanged. Related: OS#1968 Change-Id: Ibc97e1736a797ffcbf8c1f7d41c5c4518f4e41bf
2017-02-06osmo_auth*: fix ordering of function argsNeels Hofmeyr1-2/+2
milenage_gen_vec() has parameter ordering of (..., auts, rand_auts, rand). osmo_auth_gen_vec_auts() has (..., rand_auts, auts, rand), but actually feeds args in the same order, so that its rand_auts becomes auts, and its auts becomes rand_auts. Interestingly enough, API user osmo-gen-vec.c also adheres to this misordering and in turn passes auts for osmo_auth_gen_vec_auts()'s rand_auts and vice versa, so that it matches milenage_gen_vec(). So both the implementation (milenage_*) and the API user use the same ordering, just osmo_auth_gen_vec_auts() and osmo_auth_impl{ .gen_vec_auts() } in-between have the argument names swapped. Any current user of this API would need to adhere to this swapping or will not get successful AUTS resolution to a SQN. So the least impact fix is to rename the args without any actual functional change. So swap the names rand_auts and auts for osmo_auth_gen_vec_auts() and osmo_auth_impl{ .gen_vec_auts() }. (Also adjust API doc ordering) Change-Id: I0dcbd49759fc32d3b8974102dbd1d6703364ebf4
2016-06-29Make C4 function globally availableMax1-1/+1
This function perform 64 -> 128 bit key expansion which useful for converting between UMTS CK and GSM Kc, A5/3 and A5/4, GEA3 and GEA4 keys. Change-Id: I5a6c6deef6027cd6af144c9062d4c9166be26904 Related: OS#1582
2014-06-16include: Switch to #pragma once patternSylvain Munaut1-4/+1
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
2012-07-18authentication: More documentationHarald Welte1-17/+27
2012-03-21auth_milenage/osmo-auc-gen: compute OPC in case only OP is knownHarald Welte1-0/+1
2011-12-07auth_core: don't use anonymous unions to make certain gcc versions happyHarald Welte1-1/+1
2011-12-07auth_core: add functions for parsing algorithm namesHarald Welte1-0/+3
2011-12-06Add a generic abstraction for GSM/3G authentication algorithmsHarald Welte1-0/+87
Indiidual algorithms can be implemented as plugins. libosmogsm itself only provides COMP128v1 via this generic interface.
generated by cgit v1.2.3 (git 2.25.1) at 2024-05-29 08:19:26 +0000