Is the ios system secure?

Hackers have a deeper understanding of the security of smart phones than ordinary mobile phone users. Symantec's report deeply analyzes the inherent problems of Android and iOS systems, and emphatically emphasizes:

"Today, the operating system environment of mobile devices is messy and insecure. When most mobile phones are connected to the enterprise network, they are not controlled by the security of the enterprise network. Many mobile phones synchronize data with unregulated third-party cloud services. Some people connect their mobile phones to public computers with unknown security and then connect them to the corporate network. "

Don't think it has nothing to do with yourself when you see the word enterprise. In fact, mobile phone security is a problem that every mobile phone user is facing.

Pillar; pillar; mainstay

First of all, quote a passage from Na Heimberger's report:

"The development team has considered security issues when designing the latest versions of these two mobile phone operating systems, and tried to integrate security into the operating systems, thus reducing security attacks from outside."

Next, Na Heimberger tested the security precautions of Android and iOS from the following aspects:

Traditional access control: Traditional access control technologies include passwords and screen saver locks.

Permission-based access control: Permission-based access control is to add access control capability to each program.

Origin of the program: Every program will have a postmark indicating the author of the program, so as to prevent the program from being illegally modified through digital signature.

Encryption: Encrypt and hide data on portable devices.

Isolation: Isolation technology is used to limit the ability of applications to access specific sensitive data or systems.

Performance of the operating system

TechRepublic columnist Francis will first comment on the performance of Android and iOS operating systems for each pillar, and then the author will summarize according to Nachenberg's report.

Pillar 1: traditional access control

Francis: In terms of traditional access control, according to my experience, both iPhone and Android systems perform well.

However, if the fingerprint on the touch screen is too clear, it may help the hacker to crack the password of the mobile phone. In my opinion, most mobile phone developers have not added the function of locking the program by locking the screen and unlocking the operating system.

On the Android system, I use an App Protector Pro developed by Carrot App. This software allows me to add extra password protection to every program, such as Gmail, Exchange and Facebook. With this program, if my mobile phone is lost and the other party cracks the screen lock password, then I can have some extra time to modify the account password involved in these programs.

I remember that there seems to be no similar security software in iPhone. I suspect this is because iOS has a more binding sandbox model.

Kassner: Nachenberg thinks that the access control function provided by iOS can play a certain security role after the mobile phone is lost. In this regard, Nachenberg believes that the security of iOS is similar to that of Windows desktop system.

In the report, Na Heimberger was not so polite to Android. He thinks that although the Android system can also prevent accidental attacks, the Android system does not support encrypting the data in the SD card, so if the mobile phone is stolen, reading the data in the SD card directly by physical means will invalidate the password prevention function of Android.

Pillar 2: Permission-based access control

Francis: According to my experience, there are few authorization mechanisms on iOS, much less than those on Android. The only licensing mechanism that must exist is that when users access other protected subsystems, iOS will prompt users to need the corresponding resources and ask them to agree.

On the contrary, there are many such authorization mechanisms on Android. I think it is successful in theory, but in the real world, such a licensing system is not feasible, because this licensing depends on the user's understanding of science and technology in theory.

At present, four of the five hackers are using Android phones, and Android phones have gradually become mainstream smartphones. However, ordinary users are not sure whether a program should be allowed to run.

In fact, I don't think users should bear this judgment responsibility. Just like I go to the dentist's office to fill my teeth, I don't want the doctor to ask me what equipment to use when doing the necessary surgery. After all, I pay for the service. I rely on the resources of the clinic and the experience and technology of the dentist.

Kassner: I heard a lot of people talking about the licensing system in the iOS platform. Na Heimberger elaborated on this issue in his report:

"There are four types of system resources in the iOS system, and programs must be confirmed by user rights before accessing these resources. Other system resources either explicitly allow users to use software to access or explicitly prohibit users from accessing, which is the built-in isolation policy of iOS. In the following cases, the program may ask the user to confirm:

When the global positioning system of a mobile phone needs local position data,

Received a notification warning message from the Internet.

When you dial the phone.

When sending short messages or emails.

If any program tries to use the above four functions, the user will first see a permission prompt, and the program can only realize this function after the user allows it. If the user allows the function of GPS system or notification warning system, the program will be permanently allowed to use the system. For the function of making phone calls or sending text messages and emails, users need to click OK every time. "

The Android platform uses a completely different solution. It is based on the concept of "all or nothing", and I quote a passage from the Na Heimberger report to explain this concept:

"Every Android program has a license list integrated inside, which records the system functions required for the program to work normally. This list will prompt users in the process of software installation in a way that ordinary mobile phone users can understand, and users will decide whether to continue installing the software according to the security risks of the software.

If the user still chooses to install the software, the program will gain access to the corresponding system resources. If the user gives up installing the software, the program will be completely banned from running. There is no middle ground on Android. "

Pillar three: the origin of the program

Francis: In Android and iSO systems, the origin of identity and the mechanism of judging authenticity are obviously different. The pros and cons of these two mechanisms have been inconclusive, but at present there are more malware for Android than iSO.

I don't think Google's Android system is a failure in security, but a series of weak security points make the Android system more vulnerable in the face of security threats. For hackers, there is not much obstacle to developing and walking malicious software on Android system, especially when the software is classified as free or * * *, and the spread speed is faster.

Google has no review mechanism for previously submitted applications. Developers don't need to prove that they have the right to develop and modify programs. There is no centralized developer authorization. At present, there are many channels for publishing and disseminating software on Android system, and the number of channels is still increasing. The biggest loophole in the whole process is that hackers can easily obtain the software in the software store, restore it to source code through reverse engineering, add malicious code after modification and package it, and then publish it in the name of normal software.

Although the application software of iPhone can be tampered with through this series of work, the programming language of iPhone is not open, which is much more difficult to disassemble than the Java language of Google platform.

Casner: In this respect, Na Heimberger's view is the same as Francis's. IOS does better than Android in this part.

Pillar 4: Encryption

Francis: I once participated in a cross-platform mobile phone software project, which has clear privacy protection requirements, and finally an independent team of third-party engineers will review the source code.

At the beginning of this project, I found that iSO user setting data will be encrypted and stored in a certain location by default, while Android system directly puts user setting data in the corresponding program location.

This does not mean that sensitive data on Android is not encrypted, nor does it mean that the encryption technology used by Android is not as good as that of iphone. This just shows that Android will leave more encryption work to the application itself, not through the operating system. This has both advantages and disadvantages.

If you are a software developer on Android platform, your software data security may not be as good as that on iSO. However, if you set a special encryption method for your software, your software data security may be higher than iSO system, because hackers want to crack the encryption algorithm of the program.

But as a mobile phone user, you don't know whether the downloaded software has an encryption mechanism. However, if the software has no encryption mechanism, its security cannot be guaranteed, because most of the user's applications are installed on the SD card, which is easy to take out (such as inserting it into a computer to transmit data).

Kassner: Francis agrees with Nachenberg about encryption. However, I still want to talk about my views on these two platforms.

First of all, iOS uses encryption mechanism, but this is limited. Many programs run in the background (even if the user is not logged in) and need to access the stored data. In order to run normally, iOS needs to copy an unencrypted key locally. This means that for jailbroken mobile phones, hackers can access the stored data without a user password.

As Francis said, all versions of Android do not support encrypted data except version 3.0. This means that any data in the mobile phone can be browsed by jailbreak technology or any user with administrative rights.

Pillar 5: Isolation

Francis: I personally think that the isolation sandbox model of Apple and Google is safe and reliable. Compared with the two, the isolation mechanism of Android system is slightly more complicated, but it is also more flexible. Compared with the iOS system, Android can really cope with multi-tasking mode.

As a mobile phone developer, I can see the advantages brought by this mechanism. This makes us consider security issues in the process of program development, and runs through the whole development process, and the development of desktop system software can consider security issues in the last link.

Casner: Heimberger and Francis agreed again. The isolation mechanism can make different programs work separately, and it will not affect other running programs because one program is exploited by hackers.

The weakness of both

I was deeply impressed by the security performance of iOS and Android platforms. But I have to say that there are still "weaknesses" in both. Believe it or not, I believe it anyway.

Na Heimberger once mentioned to me that only a few serious vulnerabilities were found in iOS, most of which were related to jailbreak technology. But I have never heard of malware intrusion.

Android also has only a few serious vulnerabilities. But Nachenberg said that one of the vulnerabilities may allow third-party programs to gain control of the phone. And this vulnerability has been known by many hackers, one of which is called Android.Rootcager.

Android. Rootcager is a malicious software that embarrassed Google. Heimberger explained:

"More interestingly and controversially, Google's repair tool for this malware also exploits the same system vulnerability, bypassing Android's isolation system and deleting malware that poses a threat to devices."

abstract

It can be concluded that there are two heavyweight players and two different safety protection concepts. The task of this paper is to explain the difference between these two security protection mechanisms.