Security/Tizen 2.X Overview
In this section, we describe overview of Tizen security including security objectives, threat model and basic security policies. You will be able to get familiar with principles of Tizen Security.
Objective of Tizen Security Framework is to protect user privacy and assets, to protect application process and data, and to provide platform continuity and availability of Tizen devices.
Protect the user
Personal privacy is one of the most important assets nowadays, therefore user's privacy is also a primary concern of Tizen security. All user data should be protected from unauthorized access by malicious activities such as reading user data from remote, or altering user data into invalid garbage.
Moreover, most of the smart devices provide pay services such as 3G/LTE data, voice call, or premium SMS as well as application stores. The platform should protect from any unauthorized activities that can put user to expense.
Here are the examples of user assets to be protected.
- Photo, Video and Audio data
- PIMS (Contacts, call logs, calendars)
- Data network access
- Camera, Mic
- GPS, Location
- Screen capture
- Browser history and cookies
Protect the application
Building up a healthy ecosystem is the most important requirement for software platform, and there is no doubt that downloadable applications are the main component of the ecosystem. Application developers require their applications functioning as they were implemented always without any manipulation or interference, as well as confidentiality of the application code itself.
As a result, we should provide secure application runtime environment by isolating each application process and data.
Here are examples of application assets to be secured and isolated.
- Application's process (/proc)
- Application's code
- Application's created data
- Application's network connection as well as IPC
- Application's runtime info (attaching with ptrace())
|Note: Application package confidentiality is out of scope until Tizen 2.3 because Tizen Store is not the part of the platform.|
Protect the system
Continuity is one of the most important requirements for any platform or service. The platform must protect the system from malicious activities to continue functioning as designed. We need to provide integrity of the system services and resources as well as isolation between applications and system.
Here are the examples of system resources to be secured.
- System services
- Shared libraries
- System databases
- Kernel & boot loader
- Hardware drivers
- Development environment
Tizen threat model is based on security objectives, industrial practices from existing platforms and corresponding attacks.
As shown in the picture, we listed up all expected threats and mapped them to arrows. Basically we don't trust any entity including users, developers and applications. Therefore all of them should be treated as malicious and capable of harming each other. Here are the details.
- Malicious user
- A copy protected content such as paid videos or applications may be stored on the device. The user may try to access protected content and redistribute it.
- There are many usage scenarios involving in-app purchase, for example trial apps that expire in days, buying items in games. The user may try to modify an app to avoid such payment or legitimate actions.
- Some of device features can be locked by market requirements such as parental control or SIM lock. The user may try to unlock, modify or remove some of the system resources to use the device in an unauthorized way.
- Malicious developer
- Malicious developer can develop malicious applications and distribute them into an authorized or unauthorized app stores. Malicious applications can be viruses, worms, Trojans, or phishing apps.
- Unauthorized app store
- Paid applications or paid content can be distributed by unauthorized app stores.
- Malicious applications can be distributed by unauthorized app stores without any management.
- Remote hackers may try to get access to the device via internet connection
- They can manipulate vulnerabilities of any of the modules or applications in the device to get access rights of the device
- They may try to access application code and data as well as user data
- Malicious applications downloaded from any app store
- They can try to access other application process or data to steal important assets of other applications.
- They can try to impersonate system services to send IPC message, signal, or writing shared memory.
- They can try to access system resources without permission.
Basic Security Policy
- Applications are isolated
- System resources are basically isolated from applications and only authorized access is allowed
- User data is protected and only authorized access is allowed
- Applications, user, and developer do not have root privilege
- Manufacturer can allow root privilege during development.
Secure Application Life Cycle
As shown in the picture, application life cycle contains the following security measures
- In SDK
- Application signing: Application is signed by author during application development to authenticate the application's origin.
- In store
- App store signing: App store performs validation check, and signs with distributor's key to confirm that the application is allowed for distribution.
- During installation
- Anti virus check: Device checks the application package with possible anti-virus engine if exist.
- Signature verification: Distributor signature and author signature are checked along with certificates to verify the application package.
- Privilege check: Application privileges are verified basing on certificates.
- During execution
- Sandboxing: Each application is isolated and access controlled.
- Access control (not shown in the picture): Important system resources are access controlled.
Continue to Security Model