8. Security Features Motivation Viruses, spam, trojan horses have become increasingly common in PC environment In mobile environment, new kinds of opportunities offered for malicious software Potentially more personal information (e.g. calendar, phonebook, etc) Potentially more opportunities for harm (e.g. exhausting the battery, causing a loss of money) Installation-time time vs. run-time control Installation time control is easier to implement Run-time control is what is actually needed Who defines what should be allowed and what not? How to provide good enough support? 1 2 Mindset for secure design Assess risks and threats What bad things might happen and how? Adopt a mitigation strategy How to manage the identified risks? Construct a mental model to support development Sandbox, jail, safe, honeypot, etc. Settle high-level technical issues Stateless vs. stateful, use of privileges, etc. Select suitable security technologies Resolve operational issues E.g. synchronization with other devices 3 4 Design Pattern: Checkpoint Design Pattern: Roles/profiles/user types An object encapsulates the common security algorithm and policy. Determination on what is acceptable and what is not Definition of exception procedures Possibility to have uniform treatment for occasional mistakes Possibility to offer variant treatment if necessary Done at e.g. ing Set up the system so that there is only one way to log onto the system, which is via the checkpoint (single access point) Environment Checkpoint System Managing user-privilege associations becomes problematic when the number of users and privileges increase Solution: Create one or more objects that define access rights and permissions Addition of indirection Used also for program privileges User Role Privilege 5 6
Design Pattern: Secure access layer Design Pattern: Wrapping Existing infrastructure should be used whenever possible If not available, build your own low-level level security system Build a high-level secure access layer in and out of your application Application Secure access layer Network system Database system Operating system Sanity checks for parameters to guard against overflows etc. Option to create a more restricted runtime environment for a less capable mode Starting the system for the first time, allowing the wrapper to perform some extra activities Logging information Adding pre and post executed code to the system Intercepting the startup of an application for e.g. additional checks 7 8 How much of the system to reveal? Full view with errors Managing the available operations in different situations may be difficult to accomplish beforehand. Solution: Reveal everything by default. When an operation is executed, perform necessary checks. Requires a checking mechanism for the different resources that are to be used May require operating system support Limited views Getting error messages from all the different parts of the system may be frustrating for the user; designing all the error messages can be frustrating for the designer Solution: Only let the user see what he has an access to Dynamic generation of e.g. menu options In practice, one should have a common policy on how to handle the different situations; some issues might be revealed in full, whereas in some other cases limiting the options might be more natural 9 10 Goals for security features Goals for security features (cont d) Confidentiality What can be read? Often implemented with cryptographic transformations Communication User and application data Integrity Keeping information intact Often implemented with cryptographic transformations or checksums Down, installation, and startup Communication Run-time executaibles User and application data Authentication Convincing identity Often implemented with digital signatures Authorization Getting permission to act Often implemented with digital signatures Non-repudiation Impossible denial Implemented with a combination of above technologies : 11 12
Supporting hw and sw facilities in mobile devices Secure boot and software integrity checks Secure control of debug and trace capabilities Digital rights management IMEI protection and SIM lock Hardware cryptographics accelerators Hardware-based random number generator Cryptographic algorithm service Public key infrastructure (PKI) support Secure communication protocols GSM/GPRS/WCDMA security TLS/SSL IPsec Bluetooth/WLAN 13 14 Security Implementation Levels of Security Three security levels Low-level ~ virtual machine level security Application-level level ~ applications do not escape sandbox End-to-end ~ Security in all phases of e.g. a connection via e.g. encryption Digital signature to enable trusted applications (only after CLDC 1.1) Manufacturer, operator, trusted 3 rd party, untrusted Needed for phone calls, push networking features, etc User authorization may also be used if the trust level is not enough for certain feature End-to-end security: - Security in all phases of e.g. a connection via e.g. encryption Application-level security: - Virtual machine level Low-level security: - Virtual machine level 15 16 Low-level Classfile verification An application running in the virtual machine must not be able to harm the device or crash virtual machine Standard mechanism: Class file verifier that ensures that bytecode Does not include illegal instructions Cannot be executed in an illegal order Cannot contain references to illegal memory space Addition: CLDC specification states that the virtual machine must be able to reject invalid class files Enhanced class file verification required Development workstation MyApp.java javac MyApp.class preverifier MyApp.class down Target device (KVM runtime) runtime verifier interpreter 17 18
Application-level: level: Sandbox metaphor Class files to be properly verified and guaranteed to be valid Java applications Closed, predefined set of JAVA APIs available to the application programmer (CLDC, profiles (MIDP), OEM (original equipment manufacturer)) Management of Java applications at native code level inside VM, with no user-definable class ers Set of native functions offered is closed No overriding of some system classes Restrictions on dynamic class ing 19 20 Levels of Trust Levels of Trust Higher-level applications Trusted environment Trusted programming base Trusted hardware base High-level applications Common applications Trusted environment Use of communication, user interface, data base, security libraries Trusted computing base Safe saving of data, identification and authorization of software. Automatic trust in different TCB components Includes THB Trusted hardware base 21 22 Installation Time Control Run-time Control Checkpoint scheme Installation warnings can be overridden by the user No separation between installed and built-in in applications In old versions, when in the device, everything can be accessed New versions (v.9) provide support for run-time security features Capability based security Capabilities holding priviledges assigned to components Capability checks performed, whenever... a is ed IPC is performed 23 24
and Capabilities IPC and Capabilities Capability B ing failure run with Illegal IPC call requiring Capability B for IPC Capabilities B and C Capabilities C and D 25 26 Data Security Some data security related features have been implemented Disc locations can be made private to applications Binaries of applications cannot be read by normal applications Implemented in terms of capabilities [Optional] 27 28 Summary Security requires consideration at several levels of abstraction Network Device s resources Data Install-time time vs. run-time control of priviledges to perform operations Number of security related patterns Checkpoint and single access point Layered security for communications Wrapping Practical implementations in place Java and sandbox Symbian and capabilities 29