Adding Authentication and Encryption to the Public ReleaseThis work is currently hosted in openbts/features/a3a8 and subscriberRegistry/features/a3a8. Changes are required in both OpenBTS and sipauthserve. Authentication
The C2.8 commercial release currently supports A3/A8 authentication via a
SIP interface modeled on the IMS authentication exchange. This
procedure is similar to SIP digest authentication, but using the RAND as
a the nonce and an externally-supplied A3/A8 algorithm in place of MD5
or SHA2. An implementation of COMP128v1 is provided as an example A3/A8.
This capability was brought into the subscriberRegistry/features/a3a8 branch of the public release in r2583 and into the openbts/features/a3a8 in r2878. So at this point, these feature branches, together, support authentication for COMP128v1 SIMs. But as of r2878 they do not yet support encryption. Adding EncryptionTo add encryption to this system, we need to:
The total authentication/encryption process is:
(We need a new message flow diagram for this.) This is all for a minimal first-cut implementation. For longer term, scalable ciphering support, we will need other work as well, but we can deal with that once this basic plan is in place. The phases of implementation are:
Generating KcKc is generated along with SRES and CKSN when comp128v1 (or any other A3/A8) is invoked in SubscriberRegistry?. Acquiring it is just a matter of adding a little extra string processing to sipauthserve. Sending Kc and CKSN to OpenBTSKc and CKSN should be communicated to OpenBTS in the final 200 OK response from sipauthserve. Suggestion: Use SIP 200 OK message with Authentication-Info header set to Kc, and cnonce value set to CKSN. Reasoning:
Implementation: Available via following repositories:
Storing Kc and CKSN Locally in OpenBTSWhen Kc and CKSN arrives in the 200 OK, they should be stored locally in the TMSI table. When a channel is actually using Kc, the active Kc value is also stored in the L1FEC for that channel. A Kc value of zero will indicate that cihpering is off. Setting the Kc value on the L1FEC results in immediate application of the new ciphering setting. The actual Kc value should be kept in L1FEC, with accessor in the L1Encoder and L1Decoder classes and a passthrough accessor in LogicalChannel so that it can also be presented in the transaction table records. Cipher Stream GenerationFor licensing compatibility with both the public and commercial releases, the A5/1 cipher stream generator needs to be under a permissive (non-copyleft) license, like this one. Maybe we can speed that up a little if nobody else has. The proper place for cipherstream generation is in the lower parts of L1. See the next section for details. Cipher Stream Application
An earlier plan called for Kc to be in GSM::L1FEC and accessed from there by GSM::L1Encoder and GSM::L1Decoder. DownlinkThe best place to apply the downlink cipher stream is in XCCHL1Encoder::transmit() in GSM/GSML1FEC.cpp. UplinkThe best place to apply the uplink cipher stream is in TCHFACCHL1Decoder::processBurst() for TCH/F+FACCH and XCCHL1Decoder::processBurst() for everything else. Both of these are in GSM/GSML1FEC.cpp. Attachments
注:Adding Authentication and Encryption to the Public Release(原文出处,翻译整理仅供参考!) |