Apple's second iOS 10 beta includes unencrypted 32-bit bootloader, RAM Disk, more

Posted:
in iPhone edited July 2016
Apple turned heads in June when it released a preview version of iOS 10 containing an unencrypted kernel cache, a significant shift in software security policy meant to streamline system performance, and analysis shows the company is building on those efforts with the second beta release.




In a tweet on Wednesday, security expert Jonathan Zdziarski noted that the second iOS 10 beta leaves even more OS components unencrypted than the first preview version, the MIT Technology Review reports. Researchers clarified much more than kernel cache unobscured.

According to a chart compiled by noted iPhone software expert "MuscleNerd," 32-bit bootloaders, all kernel caches and all RAM Disks (except for Apple TV) are unencrypted in iOS 10 beta 2. In comparison, no bootloaders or RAM Disks were left unencrypted in the first beta version.

The latest release aligns with what appears to be a shift in Apple's approach toward software security. Instead of keeping all aspects of its next-generation mobile operating system under lock and key, the company is opening up certain components to developer scrutiny. The unobscured iOS 10 kernel cache is a prime example.

Since the inception of iOS (previously iPhone OS), Apple has obfuscated the kernel to discourage illicit probing that could inherently weaken system integrity. With iOS 10, however, Apple is relaxing those strict policies by leaving the kernel cache unencrypted, a move it says optimizes system performance. As the cache does not include sensitive information, leaving it unobscured poses no risk to end users.

Researchers speculate the move also benefits Apple's bug reporting efforts. The more eyes on iOS 10, the higher the chance of fleshing out overlooked flaws that can be fixed prior to public release this fall.

Apple has not commented on its decision to expand system transparency, nor has it provided comprehensive list of newly unencrypted iOS 10 assets.

Comments

  • Reply 1 of 16
    cpsrocpsro Posts: 3,192member
    How does use of an unencrypted boot loader make a dent in system performance?
  • Reply 2 of 16
    TurboPGTTurboPGT Posts: 355member
    These are things typically not encrypted on other systems.
    jbdragon
  • Reply 3 of 16
    thewhitefalconthewhitefalcon Posts: 4,453member
    cpsro said:
    How does use of an unencrypted boot loader make a dent in system performance?
    Even with hardware-accelerated encryption it still has to load/unload it. And iOS 10 boots and shuts down much faster than any version of iOS in recent memory.
    fastasleepDeelronlolliverredgeminipajbdragonmacguicornchip
  • Reply 4 of 16
    ericthehalfbeeericthehalfbee Posts: 4,485member
    Maybe this will also be  shift in how Apple deals with security. They might even start offering a bug bounty.
  • Reply 5 of 16
    cpsrocpsro Posts: 3,192member
    cpsro said:
    How does use of an unencrypted boot loader make a dent in system performance?
    Even with hardware-accelerated encryption it still has to load/unload it. And iOS 10 boots and shuts down much faster than any version of iOS in recent memory.
    ARM A6 and later are kinda fast. A millisecond faster, for a small bit of code that's executed once, is "much faster" or even more important than security? I don't think that justifies opening it up to modification. But somehow opening the boot loader to sanctioned 3rd party modifications in a secure manner might warrant the lack of encryption. If not encrypted, it can still be digitally signed--with Apple holding the keys. I expect Apple has some surprises in store concerning this.
    edited July 2016
  • Reply 6 of 16
    9secondkox29secondkox2 Posts: 2,664member
    Wouldn't be surprised is the true reason behind this move is to allow a government workaround when "encrypted" data is otherwise inaccessible. 
    BabysGotTheBends
  • Reply 7 of 16
    This is most definitely a new strategy that I think will enable Apple to discover flaws in the pre-release software. I wonder if the unencrypted areas are the areas Hacker's have focused their attention on in the past?

  • Reply 8 of 16
    sandorsandor Posts: 655member
    This is most definitely a new strategy that I think will enable Apple to discover flaws in the pre-release software. I wonder if the unencrypted areas are the areas Hacker's have focused their attention on in the past?

    i think this is the big reason. 

    as the user base has grown, new OS releases have been riddled with pockets of users who experience problematic bugs. 
    if there is no impact on user data security, opening parts of the OS like this allow 10.0 to behave more like a non-beta software version, Apple & its customers win.
  • Reply 9 of 16
    mjtomlinmjtomlin Posts: 2,673member
    cpsro said:
    Even with hardware-accelerated encryption it still has to load/unload it. And iOS 10 boots and shuts down much faster than any version of iOS in recent memory.
    ARM A6 and later are kinda fast. A millisecond faster, for a small bit of code that's executed once, is "much faster" or even more important than security? I don't think that justifies opening it up to modification. But somehow opening the boot loader to sanctioned 3rd party modifications in a secure manner might warrant the lack of encryption. If not encrypted, it can still be digitally signed--with Apple holding the keys. I expect Apple has some surprises in store concerning this.
    It is not opened up for modification. Why would you think that? They didn't open source it or add API's, they just unencrypted it so that it can be looked over by developers outside of Apple. Furthermore, just because the developer release is unencrypted it does not mean the final release will be as well. It's obvious Apple is trying to get more people to look over their code to help plug security holes.

    There's absolutely no reason why anyone stuff needs to worry about it.
    jbdragonmacgui
  • Reply 10 of 16
    mike1mike1 Posts: 3,275member
    sandor said:
    This is most definitely a new strategy that I think will enable Apple to discover flaws in the pre-release software. I wonder if the unencrypted areas are the areas Hacker's have focused their attention on in the past?

    i think this is the big reason. 

    as the user base has grown, new OS releases have been riddled with pockets of users who experience problematic bugs. 
    if there is no impact on user data security, opening parts of the OS like this allow 10.0 to behave more like a non-beta software version, Apple & its customers win.
    Is it possible that it is unencrypted in beta form to discover flaws and bugs and then encrypt in the final release? Just wondering.
    macgui
  • Reply 11 of 16
    arlorarlor Posts: 532member
    There's a big difference between unencrypting the compiled bootloader and kernel and releasing the uncompiled source code. The latter would facilitate bug-finding and modification; the former could to some extent but is likely just to increase performance. 
  • Reply 12 of 16
    volcanvolcan Posts: 1,799member
    Why is it a 32-bit bootloader? I thought Apple was done with 32-bit anything.
  • Reply 13 of 16
    ZooMigoZooMigo Posts: 35member
    volcan said:
    Why is it a 32-bit bootloader? I thought Apple was done with 32-bit anything.
    This is, IIRC, the last version of iOS intended for 32bit chips. As such, it still needs a 32 loader. 
  • Reply 14 of 16
    cpsrocpsro Posts: 3,192member
    mjtomlin said:
    It's obvious Apple is trying to get more people to look over their code to help plug security holes.
    Yeah, sure, and that's why it's not open source.
    /s
  • Reply 15 of 16
    cpsrocpsro Posts: 3,192member

    mjtomlin said:
    cpsro said:
    ARM A6 and later are kinda fast. A millisecond faster, for a small bit of code that's executed once, is "much faster" or even more important than security? I don't think that justifies opening it up to modification. But somehow opening the boot loader to sanctioned 3rd party modifications in a secure manner might warrant the lack of encryption. If not encrypted, it can still be digitally signed--with Apple holding the keys. I expect Apple has some surprises in store concerning this.
    There's absolutely no reason why anyone stuff needs to worry about it.
    Never said there was a reason for worry. Even if unencrypted, the code can be digitally signed... and verified.
  • Reply 16 of 16
    cpsrocpsro Posts: 3,192member

    mjtomlin said:
    It is not opened up for modification. Why would you think that?
    Not yet. And "why I would think that" is so Apple might obtain government/enterprise approval for enhanced/modified security models for government-issued or enterprise-issued devices.
Sign In or Register to comment.