Just in case someone is interested - I've just pushed out changes to allow dectmon to decipher connections if it was able to track the initial key allocation (and thus knows the UAK). The PIN it uses is currently hardcoded to "0000" in src/nwk.c, so make sure to change it to use your own PIN or add brute forcing :)
If someone wants to play with this, I'm still looking for traces of Siemens phones during pairing, location updates etc :)
... NWK: 05 40 0a 03 01 18 18 0c 08 23 b1 0e 03 7d 0d 3f |.@.......#...}.?| NWK: ee 0e 08 77 1c 1c 5f aa a6 06 33 |...w.._...3| {MM-AUTHENTICATION-REQUEST} message: IE: <<AUTH-TYPE>> id: a len: 5 dst: 0x60c2e0 authentication algorithm: DSAA (1) authentication key type: User authentication key (1) authentication key number: 8 cipher key number: 8 INC: 0 DEF: 0 TXC: 0 UPC: 1 IE: <<RAND>> id: c len: 10 dst: 0x60c4c0 value: ee3f0d7d030eb123 IE: <<RS>> id: e len: 10 dst: 0x60c4e0 value: 3306a6aa5f1c1c77
NWK: 85 41 0d 04 ba 5b b8 af |.A...[..| {MM-AUTHENTICATION-REPLY} message: IE: <<RES>> id: d len: 6 dst: 0x60c660 value: afb85bba
authentication successful DCK: 30 e5 60 b3 b9 f6 ee e8 |0.`.....|
NWK: 05 4c 19 02 81 98 |.L....| {MM-CIPHER-REQUEST} message: IE: <<CIPHER-INFO>> id: 19 len: 4 dst: 0x60c2b0 enable: 1 cipher algorithm: DECT Standard Cipher 1 (1) cipher key type: derived (9) cipher key num: 8
ciphering enabled: FP->PP ciphering enabled: PP->FP
NWK: 83 0d 1e 02 80 88 7c 04 90 02 00 84 |......|.....| {CC-SETUP-ACK} message: IE: <<PROGRESS-INDICATOR>> id: 1e len: 4 dst: 0x60c660 Location: user (0) Progress description: In-band information or appropriate pattern now available (8) IE: <<CODEC-LIST>> id: 7c len: 6 dst: 0x60c940 Negotiation Indicator: codec negotiation (1) Codec 1: Codec: G.726 (32kbit) (2) MAC/DLC Service: DLC service: LU1, MAC service: I_NA (0) Slot size: full slot (4) C-Plane routing: C_S only (0)
Hi
Do you know if there is a convention for the cipher key number and the uak number? Usually i assume that they are 0 or 8, but i don't know a way to guess them except eavesdrooping on the key exchange.
"Patrick McHardy" kaber@trash.net schrieb:
Just in case someone is interested - I've just pushed out changes to allow dectmon to decipher connections if it was able to track the initial key allocation (and thus knows the UAK). The PIN it uses is currently hardcoded to "0000" in src/nwk.c, so make sure to change it to use your own PIN or add brute forcing :)
If someone wants to play with this, I'm still looking for traces of Siemens phones during pairing, location updates etc :)
... NWK: 05 40 0a 03 01 18 18 0c 08 23 b1 0e 03 7d 0d 3f |.@.......#...}.?| NWK: ee 0e 08 77 1c 1c 5f aa a6 06 33 |...w.._...3| {MM-AUTHENTICATION-REQUEST} message: IE: <<AUTH-TYPE>> id: a len: 5 dst: 0x60c2e0 authentication algorithm: DSAA (1) authentication key type: User authentication key (1) authentication key number: 8 cipher key number: 8 INC: 0 DEF: 0 TXC: 0 UPC: 1 IE: <<RAND>> id: c len: 10 dst: 0x60c4c0 value: ee3f0d7d030eb123 IE: <<RS>> id: e len: 10 dst: 0x60c4e0 value: 3306a6aa5f1c1c77
NWK: 85 41 0d 04 ba 5b b8 af |.A...[..| {MM-AUTHENTICATION-REPLY} message: IE: <<RES>> id: d len: 6 dst: 0x60c660 value: afb85bba
authentication successful DCK: 30 e5 60 b3 b9 f6 ee e8 |0.`.....|
NWK: 05 4c 19 02 81 98 |.L....| {MM-CIPHER-REQUEST} message: IE: <<CIPHER-INFO>> id: 19 len: 4 dst: 0x60c2b0 enable: 1 cipher algorithm: DECT Standard Cipher 1 (1) cipher key type: derived (9) cipher key num: 8
ciphering enabled: FP->PP ciphering enabled: PP->FP
NWK: 83 0d 1e 02 80 88 7c 04 90 02 00 84 |......|.....| {CC-SETUP-ACK} message: IE: <<PROGRESS-INDICATOR>> id: 1e len: 4 dst: 0x60c660 Location: user (0) Progress description: In-band information or appropriate pattern now available (8) IE: <<CODEC-LIST>> id: 7c len: 6 dst: 0x60c940 Negotiation Indicator: codec negotiation (1) Codec 1: Codec: G.726 (32kbit) (2) MAC/DLC Service: DLC service: LU1, MAC service: I_NA (0) Slot size: full slot (4) C-Plane routing: C_S only (0)
On 13.11.2010 17:44, Erik Tews wrote:
Hi
Do you know if there is a convention for the cipher key number and the uak number? Usually i assume that they are 0 or 8, but i don't know a way to guess them except eavesdrooping on the key exchange.
The key numbers are contained in the authentication and cipher request messages (see below, 8 means key 0 associated with the current IPUI/PARK pair).
I've so far not seen any phone using anything else but key number 0 and especially for the cipher key that also doesn't seem to make much sense since ideally its generated directly before its used. In case of the authentication key I don't think its even possible for a normal phone to have more than one since you can't derive it from an existing UAK, so it would have to pair multiple times. Its probably intended for using foreign keys like GSM or a DAM.
Anyways, what you could do to get the authentication key number instead of eavesdropping is to send a message to the FP that will trigger authentication using the IPUI of the phone you're interested in.
{MM-AUTHENTICATION-REQUEST} message: IE: <<AUTH-TYPE>> id: a len: 5 dst: 0x60c2e0 authentication algorithm: DSAA (1) authentication key type: User authentication key (1) authentication key number: 8 cipher key number: 8 INC: 0 DEF: 0 TXC: 0 UPC: 1
{MM-CIPHER-REQUEST} message: IE: <<CIPHER-INFO>> id: 19 len: 4 dst: 0x60c2b0 enable: 1 cipher algorithm: DECT Standard Cipher 1 (1) cipher key type: derived (9) cipher key num: 8
Am 13.11.2010 17:35, schrieb Patrick McHardy:
Just in case someone is interested - I've just pushed out changes to allow dectmon to decipher connections if it was able to track the initial key allocation (and thus knows the UAK). The PIN it uses is currently hardcoded to "0000" in src/nwk.c, so make sure to change it to use your own PIN or add brute forcing :)
Its configurable now using -p/--auth-pin=PIN.
-
Erik Tews -
Patrick McHardy