1 / 41

EM406 Mobile Data Security

EM406 Mobile Data Security. Dave Neudoerffer VP of Software Engineering iAnywhere Solutions Dave.Neudoerffer@ianywhere.com. Mobile Data Security. Why? Mobile computing: Necessitates exchanging confidential data over public networks

curt
Download Presentation

EM406 Mobile Data Security

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. EM406 Mobile Data Security • Dave Neudoerffer • VP of Software Engineering • iAnywhere Solutions • Dave.Neudoerffer@ianywhere.com

  2. Mobile Data Security • Why? • Mobile computing: • Necessitates exchanging confidential data over public networks • Storing data on portable devices that are more easily lost or stolen • Wireless networks

  3. What security problem are you trying to solve? How expensive is the implementation and infrastructure? How difficult is it for users to follow security procedures? How expensive is it to the organization to follow the security procedures? Where to Start?

  4. General Observations • Costs must be compared to cost and risk of security breech • No solution is perfect  security is reducing risk not eliminating risk • If security is cumbersome, it will likely be circumvented • User education is important

  5. Agenda • What’s the Problem? • Security Overview • Discuss each Mobile Data Security Problem

  6. What security problem are you trying to solve? Interception of data transmission User authentication Rogue access to data on device Loss of device What’s the problem?

  7. Where? Thin client applications Email Voice Data synchronization Client/Server communications Messages and alerts Interception of Data Transmissions

  8. Interception of Data Transmissions • What is the Attack? • Confidentiality: we want our communications to remain private • Integrity: we want our communications to remain intact • Non-repeatable: a recording of the stream should not be useful if it is resent to the server • Authentication: we want to ensure we know who we are communicating with on the other end (no man-in-the-middle attack)

  9. User Authentication • Who? • Is the client that has connected to your server an authorized client • What is that client allowed to do • As a client, have you connected to the server you want • More complicated in message systems

  10. Rogue Access to Data on Device • Services on Device may respond to data requests • Laptops connected to internet • Drive shares • FTP server • Any type of server (database, web server, etc.) • Not many services yet on handhelds

  11. How to protect against stolen data? Data persistently stored on the device Hard disks Persistent memory Removable flash cards (both in device and out) Running applications Always-on devices Data on screen Stored in application memory Loss of Device

  12. Background Info on Security • Communication Architecture • Public Key Cryptography • Digital Certificates • Digital Signatures • Symmetric Key Cryptography • Security Protocols

  13. Communication Architecture Application Security Protocol SSL, TLS, WTLS DES, RC4, RSA Encryption Transport Layer TCPIP Physical Hardware

  14. Public Key Cryptography • Based on pairs of large associated numbers called keys • Public key can be published • Private key is kept private • Data encrypted with one can only be decrypted with the other • examples: RSA, Diffie-Hellman, Elliptic Curve Cryptography (ECC)

  15. Digital Certificates • Identity info • name, company, address • Public key • Expiry date • Digital signature(s) • made with the private key of the certificate authority • May have third-party signatures to confirm identity •  prevent modification

  16. Digital Signatures • Process: • Digest of the document is produced using one way hash • MD5, SHA-1 • Difficult to match after document modification • Digest is encrypted using the private key • Protects against document modification • Know it came from the signer

  17. PKI – Public Key Infrastructure • Certificate Authority • Issues certificates • Certificate infrastructure for security • Systems and software based on certificate security • Certificate management • Revocation lists • Certificate distribution

  18. Symmetric Key Cryptography • Same key used to encrypt and decrypt data • Much faster than public key • Stream ciphers • Cipher produces a random stream from the key that is XORed with the plaintext • Key should never be reused • RC4, SEAL • Block ciphers • Cipher transforms a block of data into a seemingly unrelated block of data of the same size • DES, Blowfish, Twofish, Rijndael, MDSR

  19. TLS/SSL Protocol • SSL 3.0 – 1996 specification from Netscape • TLS 1.0 – 1999 specification from IETF • Not compatible with SSL, but will negotiate down • 2 components: • Complex handshake for protocol negotiations • Algorithms negotiated • Certificates exchanged • Public key algorithm used to exchange symmetric key info • Messaging definition for data exchange • Symmetric encryption used • Each message signed to prevent alteration

  20. SSL Handshake Server Authentication Mode Certicom Message sizes Client Server Client Hello ~40 bytes Server Hello Server Certificate Chain ~500 bytes per cert Client Key ExchangeFinished ~80 bytes Finished ~50 bytes Application Data

  21. SSL Handshake Server Authentication Mode • Random bytes generated on each side and exchanged • Server must encrypt clients random bytes and send back to prove it has the private key  called a challenge • Randomness ensures session cannot be replayed against either side • Random bytes also used to generate symmetric keys and hashing keys using fixed algorithms that both client and server know • Symmetric key then used to encrypt application data • Hashing key used to sign messages

  22. Where are We? • What security problem are you trying to solve? • Interception of data transmission • User authentication • Rogue access to data on device • Loss of device

  23. Interception of Data Transmissions Mobile Data Arhcitectures Server Mobile Unit • Screen display info-browser control Thin Client -- Browser Web Server App Server Smart Client – Local Data Database Server • Raw Data-Application control on both ends

  24. Interception of Data Transmissions • Thin client applications • Rely on browser SSL • Email • Rely on email provider • Voice • Not much protection • Messages and alerts • Rely on infrastructure provider • Broadbeam ExpressQ uses userid/password authentication and Certicom encryption libraries • Watch for weakest link!

  25. Data Synchronization Interception of Data Transmissions TLS MobiLink Server Database Server UltraLite dbmlsync ASA Client/Server Communications TLS ASA Server Client App

  26. SQL Anywhere Communication Security • Synchronization Stream (new in 7.0) • Client/Server Comm (new in 8.0) • Certicom TLS • ECC public key (faster and smaller than RSA) • RC4 symmetric cipher • Server certificates for server authentication • Tools for generating and requesting certificates • See certificate white paper http://www.sybase.com/detail/1,3693,1009621,00.html

  27. SQL Anywhere Communication Security • Synchronization Stream (new in 7.0) • Client/Server Comm (new in 8.0) • User authentication achieved through Userid/Password • UltraLite userid/password • Dbmlsync – specify userid/password on command line or prompt • ASA userid/password

  28. SQL Anywhere Communication Security • Mechanics: • gencert utility • Used to generate certificates • Can generate certificate chains • reqtool utility • Certicom's tool for generating a request for a certificate which they will sign • Outlined in “MobiLink transport-layer security and digital certificates” white paper found at www.ianywhere.com/developer

  29. SQL Anywhere Communication Security • Specify certificate for MobiLink/ASA/UltraLite • Dbmlsrv8 –x tcpip(security=certicom_tls(certificate=mobilink.crt; certificate_password=tJ1#m6+W)) … • CREATE SYNCHRONIZATION DEFINITION testSITE 'user001'TYPE tcpip ADDRESS 'host=myhost;security=certicom_tls(trusted_certificates=mobilink.crt)' … • Ulgen –r mobilink.crt

  30. SQL Anywhere Communication Security • Specify certificate for ASA client/server • Dbsrv8 –ec certicom(certificate=sample.crt;certificate_password=certpwd) … • Connection string or ODBC connection parms: “uid=dba; pwd=sql; links=tcpip; encryption=certicom(trusted_certificates=sample.crt)”

  31. Where are We? • What security problem are you trying to solve? • Interception of data transmission • User authentication • Rogue access to data on device • Loss of device

  32. Rogue Access to Data on Device • Laptops • Hooked up to the internet • Always-on connections are of particular concern • Dialup also a concern • Install personal firewall • BlackIce, ZoneAlarm • Be careful with any servers installed on the machine • Eg. FTP, drive shares, device management software etc. • Handhelds • Not many server services -- device management software

  33. Where are We? • What security problem are you trying to solve? • Interception of data transmission • User authentication • Rogue access to data on device • Loss of device

  34. Loss of Device • Data Stored Persistently on Device • Encrypt sensitive data • Encrypt entire file system • Always On – Running Applications • Password protected timeout on device • Devices must lock down • Application code to verify user has not defeated device password protection

  35. SQL Anywhere Persistent Data Encryption • UltraLite and ASA data stores (new in 8.0) • Rijndael (rine doll) encryption • Key must not be stored on device • If you lose the key, you are toast!

  36. ASA Store Encryption • Specify key when database is created • CREATE DATABASE ‘test.db’ ENCRYPTED KEY ‘this is the password’ • Key required to start database and for utilities • dbeng8 test.db –ek “this is the password” • Dbping -c “uid=dba; pwd=sql; dbf=edb.db; dbkey=this is the password” • dbtran test.log –ek “this is the password”Will prompt for key using –ep switch •  Key is case sensitive! • All files encrypted: • Main database file, dbspace files, transaction log file, temporary files

  37. UltraLite Store Encryption • Uses Rijndael AES encryption algorithm • ULEnableStrongEncryption() called before db_init() • Key= UL_STORE_PARMS used to specify key on db_init call • First sync will create encrypted database, all calls to db_init must specify key parameter • On Palm, ULAppLaunch is called every time the application is switched to •  must provide key •  also must provide key on synchronization for HostSync conduit • No memory penalty if you don’t use store encryption

  38. Summary • Identify the security problem you are trying to solve: • Interception of data transmission • User authentication • Rogue access to data on device • Loss of device • Design an appropriate solution taking into account risks and costs. • Identify the Weakest Link!

  39. Ask the Experts - about Mobile & Wireless Solutions -Mezzanine Level Room 15B Mon./Tues. 11:30 am - 3:30 pm; Wed. 11:30 - 1:30; Thurs. 9 am - 12 noon -Exhibit Hall - Demo Center(truck) exhibit hall hours SIG (Special Interest Group) - Tuesday 5:30pm Mobile & Wireless SDCC, Upper level, Room 11 Keynote - Enabling m-Business Solutions Wednesday 1:30 pm - 3:00 pm iAnywhere Solutions Developer Community -Excellent resource for commonly asked questions, newsgroups, bug fixes, newsletters, event listings - visit www.ianywhere.com/developer iAnywhere Solutions Highlights

  40. The END

More Related