Your SlideShare is downloading. ×
0
Mobile security
Mobile security
Mobile security
Mobile security
Mobile security
Mobile security
Mobile security
Mobile security
Mobile security
Mobile security
Mobile security
Mobile security
Mobile security
Mobile security
Mobile security
Mobile security
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Mobile security

900

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
900
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
31
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
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
  • Transcript

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

    ×