Presentation on theme: "Security Issues in Mobile Communication Systems"— Presentation transcript:
1Security Issues in Mobile Communication Systems N. AsokanNokia Research CenterIAB workshop on wireless internetworkingFebruary 29 - March 2, 2000
2What is different about wireless networks? Low bandwidthminimize message sizes, number of messagesIncreased risk of eavesdroppinguse link-level encryption ("wired equivalency")Also wireless networks typically imply user/device mobilitySecurity issues related to mobilityauthenticationchargingprivacyFocus of this presentationMessage size: choose appropriate cryptographic algorithms, use compressionNumber of messages: e.g., use derived keys
3Overview Brief overview of how GSM and 3GPP/UMTS address these issues Potential additional security concerns in the "wireless Internet"Ways to address these concerns, and their implications
4GSM/GPRS security Authentication one-way authentication based on long-term shared key between user's SIM card and the home networkChargingnetwork operator is trusted to charge correctly; based on user authenticationPrivacydatalink-level encryption over the air; no protection in the core networkidentity/location/movements, unlinkabilityuse of temporary identifiers (TMSI) reduce the ability of an eavedropper to track movements within a PLMNbut network can ask the mobile to send its real identity (IMSI): on synchronization failure, on database failure, or on entering a new PLMNnetwork can also page for mobiles using IMSI
53GPP/UMTS enhancements (current status) Authenticationsupport for mutual authenticationChargingsame as in GSMPrivacydatasome support for securing core network signaling dataincreased key sizesidentity/location/movements, unlinkabilityenhanced user identity confidentiality using "group keys"a group key is shared by a group of usersOther improvementsintegrity of signaling, cryptographic algorithms made publiclarge groups: increased exposure of group keynetwork may still page using IMSIs; may also ask for IMSI
6Enhanced user identity confidentiality IMSI is not sent in clear. Instead, it is encrypted by a static group key KG and the group identity IMSGI is sent in clear.ServingNodeHomeEnvironmentUSIMIMSI requestIMSGI | E(KG, random bits| IMSI | redundancy bits)IMSI
7What is different in the wireless Internet? Potentially low cost of entry for ISPs supporting mobile accessConsequently, old trust assumptions as in cellular networks may not hold herebetween user and home ISPbetween user and visited ISPbetween ISPsImplications: potential need forincontestable chargingincreased level of privacyRelevant even in cellular networks?example: mom-and-pop outfits offering wireless Internet connectivitythe potnetial needs may be relevant even in cellular networks (e.g., as evidenced by the changes from GSM to 3G); but in the Internet they are likely to be more urgent.
8Incontestable charging Required security service: unforgeabilityCannot be provided if symmetric key cryptography is used exclusivelyhybrid methods may be used (e.g., based on hash chains)Authorization protocol must support some notion of a "charging certificate"used for local verification of subsequent authorization messagesVisited domainHome domainCharging certificateusualy this exchange results in session keys being distributed; but for non-repudiability, some sort of certificate needs to be distributedUser
9Enhanced privacy Stronger levels or privacy temporary id = home-domain, E(K, random bits| real-id )using public key encryptionK is the public encryption key of the home-domainusing opaque tokensK is a symmetric encryption key known only to the home-domaintokens are opaque to the mobile useruser requires means of obtaining new tokensno danger of loss of synchronizationIdentity privacy without unlinkability is often not usefulstatic identities allow profiles to be built up over timeencryption of identity using a shared key is unsatisfactory: trades off performance vs. level of unlinkabilityshared key: two approachesgroup key as in 3G: exposureindividual key: cannot send a key ID -> impractical
10Enhanced privacy (contd.) Release information on a need-to-know basis: e.g., does the visited domain need to know the real identity?typically, the visited domain cares about being paidground rule: stress authorization not authenticationrequire authentication only where necessary (e.g., home agent forwarding service in Mobile IP)
11An example protocol template VisitedDomainHomeDomainUserHome, E(PKH, U, V, PKU,…) SigU(...)E(PKH, U, V, PKU,…), ...SigH(PKU...)unforgeable registration requestreal identity not revealed to the visited domain
12Implications Public-key cryptography can provide effective solutions increased message sizes: use of elliptic curve cryptography can helplack of PKI: enhanced privacy solution does not require a full-fledged PKI, some sort of infrastructure is required for charging anywayAre these problems serious enough?trust assumption may not change so drasticallyproviding true privacy is hard: hiding identity information is irrelevant as long as some other linkable information is associated with the messagestry not to preclude future solutione.g., don’t insist on authentication when it is not essentialprovide hooks for future usee.g., 16-bit length fields to ensure sufficient room in message formats
13Summary Trust assumptions are different in the Internet Enhanced levels of security services may be necessaryPublic-key cryptography can provide effective solutionsTry not to preclude future provision of improved security services
15Reducing number of messages Visited domainHome domainVisited domainHome domainUserUserInitial shared key KUHInitial shared key KUHKUV f (KUH, V, …)authUH, ...authUH, authUV, ...authUH, ...authUH, ...KUV f (KUH, V, …)KUVKUVKUVKUVKUVDerive session keys as functions of long term keys plus transient informationuser can compute the session key unilaterallyKUVauthUV, ...
16Elliptic curve cryptosystems Comparison between discrete log based systems of equivalent strength in different groupsDSA: system parameters = 2208 bits, public key = 1024 bits, private key = 160 bits, signature size = 320 bitsECDSA: system parameters = 481 bits, public key = 161 bits, private key = 160 bits, signature size = 160 bitsComparison between EC and RSA of "equivalent strength"RSA: public key = 1088 bits, private key = 2048 bits, signature size = 1024 bits(taken from Certicom's white papers)