Back to index
Security Issues in a CDPD Wireless Network
Yair Frankel et al.
One-line summary: CDPD security weak point is unauthenticated,
unencrypted traffic from MSF to MHF (BS to HLR), and lack of authentication
in initial mobile/BS key exchange. Proposed solution is challenge-response
protocol ("breaking symmetry") with nonces, with extensions described
for dealing with faults, anonymity. C/R protocol embeds its messages within
existing CDPD messages, so no need to add more messages.
Overview/Main Points
- CDPD MSF and MHF (think: BS and HLR) exchange unauthenticated, unencrypted
messages! Dangerous for CDPD, esp. since it's expicitly designed for interconnection
to other networks.
- CDPD network management messages suffer from same problem
- CDPD standard doesn't specify any minimum security on "I-interfaces"
(MSF to MHF). Firewalls are useless since each MD-IS is basically a router.
- Requirement: MES must store SHR and NEI in authenticated memory. MHF
must be trusted not to reveal MES NEI or SHR. MSF (BS) must be trusted
not to disclose session keys.
- Protocol goals: fraud prevention, availability (mis-synchronization
of SHR; see below), key agreement, anonymity, computation efficiency, prevention
of denial-of-service.
Current protocol:
- Diffie-Hellman key exchange to get session key between MES & MSF
(mobile to BS);
- mobile authenticates to its home by transmitting its encrypted NEI
(permanent identifier) and SHR (shared history record, like a call counter)
to BS;
- BS forwards this stuff to MHF in the clear.
- MHF accepts by sending (SHR+1) in clear to BS, which passes it (encrypted)
to MES.
- Threat: authentication/interception. D-H key exchange provides
no authentication, so anyone can masquerade as MSF and trick MES into revealing
its SHR, which can be used to obtain service fraudulently or cause denial
of service.
Proposed improved protocol:
- MH sends nonce and tuple (random number, SHR, NEI) "signed"
by MH. Signed can mean encrypted with shared session key in this case.
Insight: Since message contains the SHR, can think of this message
as a response to the challenge posed by MHF to mobile in step 3 of the previous
instantiation of the protocol.
- BS relays this message plus a new nonce to MHF, "signing"
the tuple with BS-to-MHF key. This message is also BS's challenge to MHF.
At this point MH and BS have authenticated themselves to MHF.
- MHF responds to challenge with new share state (SHR+1), and signed tuple
containing new nonce, SHR+1, and MES's NEI. This message will serve as
the "challenge" to the mobile in the next instnatiation
of the protocol, since it includes SHR+1.
- BS relays this to MH, encrypted in BS/MH session key.
At this point, BS and MHF have authenticated themselves to MH.
- To incorporate protocol in CDPD: must modify "protocol data units"
(state machines) for the ESH (End-station Hello) and RDR (redirect request
from BS to MHF) messages.
- Can add authenticated key exchange for confidentiality of data
- Can add anonymity (to BS anyway) by having MH encrypt its identity in
a secret key shared with MHF. CDPD existing anonymity mechanism won't work
since it requires encryptd channel from the beginning of the authentication
protocol (costly) and doesn't address interception attack. Proposal is
to have MH transmit to BS its ID encrypted with a key based on SHR and
shared secret with MHF, then BS forwards that to MHF once MHF has authenticated
itself.
Relevance
How to do link-level security, given assumption that end-to-end will be
too intrusive to integrate seamlessly with existing networks. (My view:
end-to-end will ultimately be necessary anyway for other reasons, but these
techniques can be applied there as well.)
Flaws
- Why not sign message digests instead of whole messages during the protocol?
- Decryptability of data packets in presence of packet losses: can include
cumulative byte count in each packet header. End-to-end would of course
fix this.
- Astoundingly poorly written; badly organized, and the descriptions are
difficult to follow and understand.
Back to index