Mobile security

1,116 views

Published on

Published in: Education
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
1,116
On SlideShare
0
From Embeds
0
Number of Embeds
3
Actions
Shares
0
Downloads
32
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide
  • Message size: choose appropriate cryptographic algorithms, use compression Number of messages: e.g., use derived keys
  • large groups: increased exposure of group key network may still page using IMSIs; may also ask for IMSI
  • example: mom-and-pop outfits offering wireless Internet connectivity the 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.
  • usualy this exchange results in session keys being distributed; but for non-repudiability, some sort of certificate needs to be distributed
  • shared key: two approaches group key as in 3G: exposure individual key: cannot send a key ID -> impractical
  • Derive session keys as functions of long term keys plus transient information user can compute the session key unilaterally
  • Mobile security

    1. 1. Security Issues in Mobile Communication Systems N. Asokan Nokia Research Center IAB workshop on wireless internetworking February 29 - March 2, 2000
    2. 2. What is different about wireless networks? <ul><li>Low bandwidth </li></ul><ul><ul><li>minimize message sizes, number of messages </li></ul></ul><ul><li>Increased risk of eavesdropping </li></ul><ul><ul><li>use link-level encryption (&quot;wired equivalency&quot;) </li></ul></ul><ul><li>Also wireless networks typically imply user/device mobility </li></ul><ul><ul><li>Security issues related to mobility </li></ul></ul><ul><ul><ul><li>authentication </li></ul></ul></ul><ul><ul><ul><li>charging </li></ul></ul></ul><ul><ul><ul><li>privacy </li></ul></ul></ul><ul><ul><li>Focus of this presentation </li></ul></ul>
    3. 3. Overview <ul><li>Brief overview of how GSM and 3GPP/UMTS address these issues </li></ul><ul><li>Potential additional security concerns in the &quot;wireless Internet&quot; </li></ul><ul><li>Ways to address these concerns, and their implications </li></ul>
    4. 4. GSM/GPRS security <ul><li>Authentication </li></ul><ul><ul><li>one-way authentication based on long-term shared key between user's SIM card and the home network </li></ul></ul><ul><li>Charging </li></ul><ul><ul><li>network operator is trusted to charge correctly; based on user authentication </li></ul></ul><ul><li>Privacy </li></ul><ul><ul><li>data </li></ul></ul><ul><ul><ul><li>link-level encryption over the air; no protection in the core network </li></ul></ul></ul><ul><ul><li>identity/location/movements, unlinkability </li></ul></ul><ul><ul><ul><li>use of temporary identifiers (TMSI) reduce the ability of an eavedropper to track movements within a PLMN </li></ul></ul></ul><ul><ul><ul><li>but network can ask the mobile to send its real identity (IMSI): on synchronization failure, on database failure, or on entering a new PLMN </li></ul></ul></ul><ul><ul><ul><li>network can also page for mobiles using IMSI </li></ul></ul></ul>
    5. 5. 3GPP/UMTS enhancements (current status) <ul><li>Authentication </li></ul><ul><ul><li>support for mutual authentication </li></ul></ul><ul><li>Charging </li></ul><ul><ul><li>same as in GSM </li></ul></ul><ul><li>Privacy </li></ul><ul><ul><li>data </li></ul></ul><ul><ul><ul><li>some support for securing core network signaling data </li></ul></ul></ul><ul><ul><ul><li>increased key sizes </li></ul></ul></ul><ul><ul><li>identity/location/movements, unlinkability </li></ul></ul><ul><ul><ul><li>enhanced user identity confidentiality using &quot;group keys&quot; </li></ul></ul></ul><ul><ul><ul><li>a group key is shared by a group of users </li></ul></ul></ul><ul><li>Other improvements </li></ul><ul><ul><li>integrity of signaling, cryptographic algorithms made public </li></ul></ul>
    6. 6. Enhanced user identity confidentiality <ul><li>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. </li></ul>IMSGI | E(KG, random bits| IMSI | redundancy bits) IMSI request IMSI USIM Serving Node Home Environment
    7. 7. What is different in the wireless Internet? <ul><li>Potentially low cost of entry for ISPs supporting mobile access </li></ul><ul><li>Consequently, old trust assumptions as in cellular networks may not hold here </li></ul><ul><ul><li>between user and home ISP </li></ul></ul><ul><ul><li>between user and visited ISP </li></ul></ul><ul><ul><li>between ISPs </li></ul></ul><ul><li>Implications: potential need for </li></ul><ul><ul><li>incontestable charging </li></ul></ul><ul><ul><li>increased level of privacy </li></ul></ul><ul><li>Relevant even in cellular networks? </li></ul>
    8. 8. Incontestable charging <ul><li>Required security service: unforgeability </li></ul><ul><li>Cannot be provided if symmetric key cryptography is used exclusively </li></ul><ul><ul><li>hybrid methods may be used (e.g., based on hash chains) </li></ul></ul><ul><li>Authorization protocol must support some notion of a &quot;charging certificate&quot; </li></ul><ul><ul><li>used for local verification of subsequent authorization messages </li></ul></ul>User Visited domain Home domain Charging certificate
    9. 9. Enhanced privacy <ul><li>Stronger levels or privacy </li></ul><ul><ul><li>temporary id = home-domain, E(K, random bits| real-id ) </li></ul></ul><ul><ul><li>using public key encryption </li></ul></ul><ul><ul><ul><li>K is the public encryption key of the home-domain </li></ul></ul></ul><ul><ul><li>using opaque tokens </li></ul></ul><ul><ul><ul><li>K is a symmetric encryption key known only to the home-domain </li></ul></ul></ul><ul><ul><ul><li>tokens are opaque to the mobile user </li></ul></ul></ul><ul><ul><ul><li>user requires means of obtaining new tokens </li></ul></ul></ul><ul><ul><li>no danger of loss of synchronization </li></ul></ul><ul><li>Identity privacy without unlinkability is often not useful </li></ul><ul><ul><li>static identities allow profiles to be built up over time </li></ul></ul><ul><ul><li>encryption of identity using a shared key is unsatisfactory: trades off performance vs. level of unlinkability </li></ul></ul>
    10. 10. Enhanced privacy (contd.) <ul><li>Release information on a need-to-know basis: e.g., does the visited domain need to know the real identity? </li></ul><ul><ul><li>typically, the visited domain cares about being paid </li></ul></ul><ul><ul><li>ground rule: stress authorization not authentication </li></ul></ul><ul><ul><li>require authentication only where necessary (e.g., home agent forwarding service in Mobile IP) </li></ul></ul>
    11. 11. An example protocol template Home, E(PK H , U, V, PK U, …) Sig U (...) User Visited Domain Home Domain E(PK H , U, V, PK U ,…), ... Sig H (PK U ...) <ul><li>unforgeable registration request </li></ul><ul><li>real identity not revealed to the visited domain </li></ul>
    12. 12. Implications <ul><li>Public-key cryptography can provide effective solutions </li></ul><ul><ul><li>increased message sizes: use of elliptic curve cryptography can help </li></ul></ul><ul><ul><li>lack of PKI: enhanced privacy solution does not require a full-fledged PKI, some sort of infrastructure is required for charging anyway </li></ul></ul><ul><li>Are these problems serious enough? </li></ul><ul><ul><li>trust assumption may not change so drastically </li></ul></ul><ul><ul><li>providing true privacy is hard: hiding identity information is irrelevant as long as some other linkable information is associated with the messages </li></ul></ul><ul><ul><li>try not to preclude future solution </li></ul></ul><ul><ul><ul><li>e.g., don’t insist on authentication when it is not essential </li></ul></ul></ul><ul><ul><li>provide hooks for future use </li></ul></ul><ul><ul><ul><li>e.g., 16-bit length fields to ensure sufficient room in message formats </li></ul></ul></ul>
    13. 13. Summary <ul><li>Trust assumptions are different in the Internet </li></ul><ul><li>Enhanced levels of security services may be necessary </li></ul><ul><li>Public-key cryptography can provide effective solutions </li></ul><ul><li>Try not to preclude future provision of improved security services </li></ul>
    14. 14. End of presentation <ul><li>Additional slides follow </li></ul>
    15. 15. Reducing number of messages K UV User Visited domain Home domain Initial shared key K UH auth UH , ... K UV K UV K UV auth UV , ... User Visited domain Home domain Initial shared key K UH auth UH, auth UV , ... auth UH , ... K UV K UV K UV  f (K UH , V, …) K UV  f (K UH , V, …) auth UH , ...
    16. 16. Elliptic curve cryptosystems <ul><li>Comparison between discrete log based systems of equivalent strength in different groups </li></ul><ul><ul><li>DSA: system parameters = 2208 bits, public key = 1024 bits, private key = 160 bits, signature size = 320 bits </li></ul></ul><ul><ul><li>ECDSA: system parameters = 481 bits, public key = 161 bits, private key = 160 bits, signature size = 160 bits </li></ul></ul><ul><li>Comparison between EC and RSA of &quot;equivalent strength&quot; </li></ul><ul><ul><li>RSA: public key = 1088 bits, private key = 2048 bits, signature size = 1024 bits </li></ul></ul><ul><li>(taken from Certicom's white papers) </li></ul>

    ×