Google Android:
Mobile Device Security
A Comprehensive Security Assessment
This research provides a security assessment of the Android framework—Googlersquo;s software stack for mobile devices. The authors identify high-risk threats to the framework and suggest several security solutions for mitigating them.
s an operating system for mobile devices, Googlersquo;s Android—an open, programma- ble software framework—is vulnerable to typical smart-phone attacks. Such attacks
A
can make the phone partially or fully unusable, cause unwanted SMS/MMS (short message service/multi- media messaging service) billing, or expose private information.1 Smart-phone attack vectors include cellular networks, Bluetooth, the Internet (via Wi-Fi, General Packet Radio Service/Enhanced Data Rates for Global Evolution, or 3G network access), USB, and other peripherals.2 Smart-phone malware evolve very quickly due to the experience malware writers have gained with PC malware. As Alexander Gostev estimates,3 two years are sufficient for smart-phone viruses to evolve to a level that computer viruses only reached after 20 years. Thus, the challenge in ensur- ing smart-phone security is becoming similar to that confronting the PC.4 Among the most prominent smart-phone malware types are the Lasco/Cabir5 and Commwarrior/Mabir worm families,6 the Flex- iSpy, RedBrowser, and Skulls Trojan horses, the WinCE.Duts and CardTrap viruses,7 and, recently, the iPhone ikee worm and iPhone/Privacy.A hack- ing tool that exploited vulnerabilities in jail-broken iPhone systems.
So far, smart-phone pandemic outbreaks have been limited in their scale and impact due to a re- stricted number of potential victims. Nevertheless, smart-phone market share in the US has increased from 11 percent of all cellular phone subscribers in 2008 to 17 percent in 2009, and it is expected to in- crease significantly over the next few years.8 Conse-
quently, smart phones are likely to become a fertile ground for various types of malware.
The number of smart phones based on the Google Android operating system are expected to increase 10 percent during 2010.8 The risks to Android are never- theless significant, mainly because itrsquo;s an open source software stack operated in a heterogenic mobile en- vironment. Thus, hackers can more easily access, manipulate, and exploit the operating system code. Here, we review and assess the security mechanisms incorporated into Googlersquo;s new Android framework and whether theyrsquo;re adequate in light of the emerging threats to smart phones.
Android Security Mechanisms
Android is an application execution environment for mobile devices. It includes an operating system, ap- plication framework, and core applications. The An- droid software stack is built on the Linux kernel, which is used for its device drivers, memory management, process management, and networking. The next level up contains the Android native libraries. Various system components in the upper layers use these libraries, which are written in C/C . Incorporating these libraries in Android applications is achieved via Java native interfaces. The next level is the Android run- time, comprising the Dalvik virtual machine and the core libraries. Dalvik runs .dex (Dalvik-executable) files that are designed to be more compact and memory- efficient than Java class files. The core libraries are written in Java and provide a substantial subset of the Java 5 SE packages as well as some Android-specific
AsAf shAbtAi, YuvAl fledel, uri KAnonov, YuvAl elovici, shlomi dolev, And chAnAn Glezer
Ben-Gurion University of the Negev, Israel
MARCH/APRIL 2010 ■ 1540-7993/10/$26.00 copy; 2010 IEEE ■ COPUBLISHED BY THE IEEE COMPUTER AND RELIABILITY SOCIETIES 35
Table 1. Security mechanisms incorporated in Android.
Mechanism Description Security issue Linux mechanisms
POSIX users Each application is associated with a different user ID (or UID).
File access The applicationrsquo;s directory is only available to the application.
Prevents one application from disturbing another
Prevents one application from accessing anotherrsquo;s files
Environmental features
Memory management unit (MMU) Each process is running in its own address
space.
Type safety Type safety enforces variable content to adhere to a specific format, both in compiling time and runtime.
Mobile carrier security features Smart phones use SIM cards to authenticate
and authorize user identity.
Prevents privilege escalation, information disclosure, and denial of service
Prevents buffer overflows and stack smashing
Prevents phone call theft
Android-specific mechanisms
Application permissions Each application declares which permission it requires at install time.
Component encapsulation Each component in an application (such as an activity or service) has a visibility level that regulates access to it from other applications (for example, binding to a service).
Signing applications The developer signs application .apk files, and the package manager verifies them.
Dalvik virtual machine Each application runs in its own virtual machine.
Limits application abilities to perform malicious behavior
Prevents one application from disturbing another, or accessing private components or APIs
Matches and verifies that two applications are from the same source
Prevents buffer overflows, remote code execution, and stack smashing
libraries. The application framework layer, written fully in Java, includes Google-provided tools as well as pro- prietary exten
全文共45934字，剩余内容已隐藏，支付完成后下载完整资料
外文翻译英语原文
Google Android: A Comprehensive Security Assessment
As an operating system for mobile devices, Googlersquo;s Android—an open, programmable software framework—is vulnerable to typical smart-phone attacks. Such attacks can make the phone partially or fully unusable, cause unwanted SMS/MMS (short message service/multimedia messaging service) billing, or expose private information. Smart-phone attack vectors include cellular networks, Bluetooth, the Internet (via Wi-Fi, General Packet Radio Service/Enhanced Data Rates for Global Evolution, or 3G network access), USB, and other peripherals. Smart-phone malware evolve very quickly due to the experience malware writers have gained with PC malware. As Alexander Gostev estimates, two years are sufficient for smart-phone viruses to evolve to a level that computer viruses only reached after 20 years. Thus, the challenge in ensuring smart-phone security is becoming similar to that confronting the PC. Among the most prominent smart-phone malware types are the Lasco/Cabir and Commwarrior/Mabir worm families, the FlexiSpy, RedBrowser, and Skulls Trojan horses, the WinCE.Duts and CardTrap viruses, and, recently, the iPhone ikee worm and iPhone/Privacy.A hacking tool that exploited vulnerabilities in jail-broken iPhone systems.
So far, smart-phone pandemic outbreaks have been limited in their scale and impact due to a restricted number of potential victims. Nevertheless, smart-phone market share in the US has increased from 11 percent of all cellular phone subscribers in 2008 to 17 percent in 2009, and it is expected to increase significantly over the next few years. Consequently, smart phones are likely to become a fertile ground for various types of malware.
The number of smart phones based on the Google Android operating system are expected to increase 10 percent during 2010. The risks to Android are neverthe less significant, mainly because itrsquo;s an open source software stack operated in a heterogenic mobile environment. Thus, hackers can more easily access, manipulate, and exploit the operating system code. Here, we review and assess the security mechanisms incorporated into Googlersquo;s new Android framework and whether theyrsquo;re adequate in light of the emerging threats to smart phones.
Android Security Mechanisms
Android is an application execution environment for mobile devices. It includes an operating system, application framework, and core applications. The Android software stack is built on the Linux kernel, which is used for its device drivers, memory management, process management, and networking. The next level up contains the Android native libraries. Various system components in the upper layers use these libraries, which are written in C/C . Incorporating these libraries in Android applications is achieved via Java native interfaces. The next level is the Android runtime, comprising the Dalvik virtual machine and the core libraries. Dalvik runs .dex (Dalvik-executable) files that are designed to be more compact and memoryefficient than Java class files. The core libraries are written in Java and provide a substantial subset of the Java 5 SE packages as well as some Android-specific libraries. The application framework layer, written fully in Java, includes Google-provided tools as well as proprietary extensions or services. The topmost application layer provides applications such as a phone, Web browser, email client, and more.
Each application in Android is packaged in an apk archive for installation. This archive is similar to a Java standard jar file in the way that it holds all code and noncode resources (such as images or manifest) for the application. Android applications are written in Java based on the APIs the Android software development kit (SDK) provides. William Enck and his colleagues discussed the main components of an Android application and how to use an Android-specific mechanism to protect Android applications.
In general, several security mechanisms are incorporated into the Android framework. We can cluster them into three general groups: Linux mechanisms, environmental features, and Androidspecific mechanisms.
Linux Mechanisms
There are two primary security mechanisms at the Linux layer in Android: the Portable Operating System Interface (POSIX) users, and file access. The basic element of these mechanisms is users (that is, entities). Each object (such as a process or file) is owned by a user (represented by an integer number, or user id). Users are further assigned to groups.
POSIX users. Each Android package (.apk) file installed on a device has a unique Linux (POSIX) user ID. Thus, two different packagesrsquo; code canrsquo;t run in the same process. In a way, this creates a sandbox and prevents applications from interfering with one another. For two applications to share the same permissions set and possibly run in the same process, they must share the same user ID, which is possible only using the sharedUserID feature. To share the same user ID, two applications must explicitly declare theyrsquo;re using the same sharedUserID, and both must be digitally signed by the same author.
以上是毕业论文外文翻译，课题毕业论文、任务书、文献综述、开题报告、程序设计、图纸设计等资料可联系客服协助查找。
