Apple iOS. I OS provides traditional access control security options, which include password configuration options such as account lockout options. Example: ...

寻梦者@发布于2018/06/12 00:00

注脚

1.MOBILE OS SECURITY Vivek-Vijayan University of Tennessee at Chattanooga

2. Eminent Threats  Web based and network based attacks: The mobile device is connected to the internet, browsing websites with malicious content.  Malware: traditional viruses, worms and trojan horses.  Social engineering attacks: phishing. Also used to install malware.  Resource and service availability abuse: botnet, spamming, overcharging (SMS and calls).  Attacks on the integrity of the device’s data: malicious encryption with ransom, modification of data such as address book.

3. Five Pillars  Traditional Access Control  Application Provenance  Encryption  Isolation  Permissions-based access control

4. Traditional Access Control: This mechanism seeks to protect devices using techniques such as passwords and idle-time screen locking.  Application Provenance: is an approach where each application is stamped with the identity of its author and made tamper resistant (eg: digital signature). Thus enabling a user to decide to use or not to use the application based on the identity of the author.  Encryption: is a approach to conceal data on the device to address device loss or theft.  Isolation: limits applications ability to access sensitive data or systems on a device.  Permission-based access control: grants set of permissions to each application, limiting each application to access device data/systems within the scope of the permission. Blocks the application if it attempts to perform actions exceeding the permissions given.

5. Traditional Access Control Apple iOS  I OS provides traditional access control security options, which include password configuration options such as account lockout options. Example: The strength of the passcode can be chosen by the administrator and the administrator can also specify how frequently the user can update the passcodes, and the maximum number of failed login attempts before the device wipes itself. Android  Android provides password configuration options, which include specifying the strength of the device passcode, phone’s lockout time span, failed login attempts before device wipes data, indication of password expiration, enabling administrators to compel users to update their passwords on a regular basis .

6. Effectiveness Apple’s iOS  The access control feature of the iOS provides a reasonable level of security for the devices data in the event of loss or theft.  The iOS is in par with traditional windows based desktops in this scenario. Android  The password policy system is sufficient to protect devices against casual attacks.  The previous versions of Android do not encrypt data stored on removable SD memory card, thus allowing the attacker to eject the SD memory card, and obtain the data by bypassing all password controls.

7. Application Provenance Apple iOS  Before releasing the software to iPhone, iPod, and iPad users. The developer goes through a registration process with apple and pay an annual licensing fee. The developers then “digitally sign” each app with an apple-issued digital certificate before its release. This signing process of the developer into the app proves that the app author is an apple-approved developer and the app’s logic cannot be tampered with after its creation by the developer. Through App Store  The developer submits the app for a cerifitcation by apple – approval process takes one or two weeks and then the app is deployed into the app store.  If the app is found malicious or any violation of license agreement occurs, the app is removed from the appstore, but no automated mechanism has been implemented to remove the app from the devices (iphone/ipad) after it has been installed.

8.Android  Google undermines both the goals of ensuring that the app’s logic is not tampered with and to allow the user of the app to determine the identity of the app’s author.  Android OS only installs and runs apps that have been properly signed with a digital cerificate. Unlike apple software developers need not apply to google to obtain a code-signing certificate, thus the developer can generate their own signing certificates.  This results in an malware author generating anonymous digital certificate, and no certificate or malware signed with google that can be tracked back to the author. Through google’s android market  For developers to sell their apps on android marketplace, a 25$ fee is charged via credit card, thus allowing google to associate the payee with the digital ceritificate, which may reduce the chances of distribution of malicious apps (if the developer uses his own credit card).

9. Effectiveness Apple iOS  Apple’s approach is effective as - The developer must register and pay to obtain a signing certificate from apple, which makes it more easy to identify if any malicious activities are performed. - Each and every application is tested before submission to the app- store. - Apple’s code signing model prevents tampering with published apps. Android  Since no single authority evaluates or verifies all Android apps, attackers are more likely to release attacks without worrying of getting caught.

10. Encryption Apple iOS  The iOS uses a hardware accelerated AES-256 encryption to encrypt all data stored in the flash memory of the device.  The iOS protects specific additional data items, such as email using an additional layer of encryption.  Within 10 seconds of the device locking, the decryption keys for files in device are discarded. Android  Android recently began offering built in encryption in 3.0, earlier versions of android contain no encryption capability, instead to rely on islolation and permissions to safeguard data. A simple jailbreak of an android phone, or theft of device’s SD card can lead to significant loss of data.

11. Isolation Apple iOS  iOS operating system isolates each app from every app on the system.  The apps are not allowed to modify or view each other’s data, or even know if other apps exist on the OS, nor can they access the OS kernel, nor install privileged driver’s or obtain root level administrator access to the device.  The apps are also isolated from the phone’s SMS, email in-out box and other email attachments. Android  Like iOS, Android employs a strong isolation system. It not only isolates apps from each other but also prevents apps from accessing or modifying the OS kernel, ensuring the app doesn’t get admin control over a device.

12.Blackberry (BB10):  introduces us to Blackberry Balance. Balance allows organizations to create isolation between personal and work environments on a device. Additional logical security is used to keep personal applications, files and network separate from the work environment.  When Balance is enabled, workspace is automatically encrypted, leaving personal environment unencrypted. Windows Phone 8:  WP8 uses the Unified Extensible Firmware Interface for secure boot, ensuring devices do not load rooted or unauthorized system images.  WP8 apps run in isolated “chambers”, which are similar to sandbox. Chambers keep applications and their data separate from one another.  The data between the applications is shared in the cloud and not on the device.

13. Permission Based Access Control Apple iOS  The iOS denies access under all circumstances to many of the device’s sensitive subsystems. Thus increasing the security of iOS based devices since it removes the user from security decision- making process.  The above process also limit’s each applications functionality, potentially limiting the utility of certain classes of iOS apps. Android  The Android permission system relies on the user to make all policy decisions and decide whether an apps requested combination of permission is safe or not.

14.

15. sources  http:// www.tomsitpro.com/articles/mobile_security-m obile_management,2-64-9.html  http://www.slideshare.net/vladimirjirasek/mobi le-security-summit-10-mobile-risks  http://searchconsumerization.techtarget.com/ti p/Data-and-device-encryption-on-iOS-Android- Windows-Phone-and-BlackBerry

user picture
  • 寻梦者@
  • Apparently, this user prefers to keep an air of mystery about them.

相关Slides

  • 随着移动端开发规模(Codebase大小以及同时开发人数)的不断增加,传统的基于Xcode的工程项目管理和构建面临着越来越多的问题,比如难以管理依赖关系和编译配置信息,难以创建新模块,工程项目文件经常出现Merge conflicts,过慢的编译速度导致CI系统压力大和开发效率降低。Buck是Facebook开源的一个非常流行的构建工具,已经在很多大公司以及庞大的开发环境中被使用。 但是目前开源的Buck没法完善的支持Swift环境,本文主要介绍Airbnb在应Buck来构建iOS相关项目中的实践过程和心得,包括怎么让Buck支持Objective-c和Swift混合开发环境,怎么让迁移过程平缓的进行,怎么让Buck支持已经使用Cocopods的项目,使用Buck来大幅提高构建速度,以及高效的使用Buck来管理项目和开发流程等。

  • 随着这几年的基础技术积累,移动端动态化解决方案逐渐丰富起来。但对开发者来说,动态化的道路上仍然有很多现实的技术坑,从选择动态化方案到规划动态化未来的走向,从开源项目试水到搭建动态化服务后台,实践过程中无一不是遍地荆棘。美团平台承载了数十条业务线的开发,从大家熟知的美食、外卖、电影、酒店到探索中的打车、零售等等。这些业务线之间的业务形态、发展状态等都千差万别,他们对动态化也都有各自不同的诉求。为了支持好业务线的发展,美团平台在实践中摸索出了一系列适合不同业务的动态化方案。在这里我将详细分析美团在动态化实践中踩到的坑和解决方案,希望能跟大家一起探索出移动端动态化的康庄大道。

  • 我目前是一名在UC工作的iOS开发者。曾经创业过一段时间,期间主要Swift来构建快速移动应用,以及使用Python后端全家桶(redis、mongodb、zmq等)来构建一系列app的后台服务。进入UC之后先后负责夸克浏览器的开发,Weex适配的工作,目前主要负责短视频业务,其中主要包括视频拍摄,OpenGL/Shader,视频编解码之类的工作。 喜欢Swift语言的各种先进特性,2年前加入SwiftGG后一直致力于Swift语言的布道和最佳实践的讨论。其中对利用Swift的函数式特性改进工程实践的方面研究较多,去年的第二届atSwift大会上也分享了如何通过设计一套简单的reactive api来让mvvm写起来更舒服,Swift社区大多数都叫我“莲叔”。主要当时在翻译组里,我的昵称叫小莲 :-D。

  • Android应用开发入门教程(经典版)