M421 Mobile Data Security

1. M421Mobile Data Security Dave Neudoerffer VP Engineering iAnywhere Solutions

2. Mobile Data Security Why? • Because mobile computing necessitates exchanging confidential data over public and wireless networks • Storing data on portable devices that are more easily lost or stolen • Harder to identify mobile entities • Data is valuable

3. The Revolution “By 2003/04, we expect nearly 50% of corporate knowledge workers to have notebook computers as their primary computing devices. Furthermore, we expect more than 75% of knowledge workers to be mobile at least 25% of the time.” * “By 2004, each corporate knowledge worker will have 3 to 4 different computing and information access devices that will be used to access various applications (i.e. HR systems, order placement, field dispatch, scheduling, etc.).” * * “Entering the Mobile Millennium,” META Group, Feb. 14, 2000

4. The Problem • The FBI reported Tuesday it had tentatively determined that more than … 184 laptop computers – including one that contained classified information – are unaccounted for. (CNN, July 19, 2001) • The Federal Opposition has revealed that more than 500 Commonwealth laptop computers, some containing classified Cabinet and commercial information have been lost or stolen in just one year. (ABC Australia January  16, 2002) • Denver International Airport, where hundreds of laptops and cell phones have been left, has posted "Got Laptop?" signs to prompt passengers leaving security checkpoints to check for their belongings. (Bill Bergstrom, AP, March 19, 2002)

5. What security problem are you trying to solve? How do you solve it? 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?

6. 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 • Software management systems can help

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

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

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

10. 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)

11. 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

12. Rogue Access to Data on Device • Services on Device may respond to data requests • Laptops connected to internet • Drive shares, FTP server, OS flaw • Any type of server (database, web server, etc.) • Not many services yet on handhelds • Trojans lurking on devices • Virus infection • Could compromise data on device or use device as access into enterprise

13. Loss of Device 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

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

15. Security Overview • Communication Architecture • Public Key Cryptography • Digital Certificates • Digital Signatures • Symmetric Key Cryptography • Security Protocols

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

17. 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)

18. 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

19. 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

20. 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

21. 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

22. 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

23. 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

24. 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

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

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

27. Interception of Data Transmissions • Where is your data going and what is the protection • Watch out for “the weakest link”! • Browser SSL server authentication based on IP address in certificate • Doesn’t protect against IP address spoofing • WAP GAP (WAP 1.0) • Data decrypted and reencrypted at WAP gateway • Want end to end protection  right from remote device to behind corporate firewall

28. Interception of Data Transmissions Mobile Application Architectures 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

29. Interception of Data Transmissions • Thin client apps • Email • Voice • Messaging • Mobile device management • Data synchronization • Client/Server communications

30. Interception of Data Transmissions • Thin client applications • Rely on browser SSL • Authentication must be built into web application

31. Interception of Data Transmissions • Email • Rely on email provider, most email not protected • Mail Anywhere: • End to end encryption with Certicom one pass technology • Server authentication based on public key / private key pair • User authentication based on backend email server userid/password • Standard interface and authentication to backend email server

32. Interception of Data Transmissions • Voice • Not much protection • Digital voice is harder to capture, but not strongly encrypted

33. Interception of Data Transmissions • Messages and alerts • Rely on infrastructure providers • Watch for new Message Anywhere product (now in beta)

34. Interception of Data Transmissions • Mobile management software • Manage Anywhere • Secure communications over HTTPS • Based on browser certificate registry, IIS managed server side • Typically runs inside the firewall • Admin console protected using NT authentication

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

36. 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

37. 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

38. SQL Anywhere Communication Security Mechanics: • gencert utility • Used to generate certificates • Can generate certificate chains • Outlined in “MobiLink transport-layer security and digital certificates” white paper found at www.ianywhere.com/developer

39. SQL Anywhere Communication Security • Specify certificate for MobiLink/ASA/UltraLite synchronization • 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

40. 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)”

41. 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

42. 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, database servers etc. • Handhelds • Not many server services … yet •  device management software can help

43. Rogue Access to Data on Device • Manage Anywhere • Deliver latest virus scanner updates • Run regularly scheduled virus scans and backups • Keep OS and software up to latest security patch level • Enforce security policies such as no activeXs from IE • Audit remote machine activities

44. 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

45. 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 •  backups! • Management software can be used to backup the device and to track the device

46. SQL Anywhere Persistent Data Encryption • UltraLite and ASA data stores (new in 8.0) • AES (Advanced Encryption Standard) algorithm • Rijndael (rine doll) • Casio’s MDSR encryption algorithm • Key must not be stored on device • If you lose the key, you are toast!

47. ASA Store Encryption • Specify key when database is created • CREATE DATABASE ‘test.db’ ENCRYPTED KEY ‘this is the password’ ALGORITHM [AES|MDSR] • Key required to start database and for utilities • dbeng8 test.db –ek “this is the password” • Dbping -c “uid=dba; pwd=sql; dbf=test.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

48. 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 HotSync conduit • No memory penalty if you don’t use store encryption

49. Mobile Device Management • Manage Anywhere • Automate backups • Easy software delivery and configuration in case of lost device • Track hardware devices, track software installed on devices • Implement a self destruct policy on loss of device

50. 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!