mikeash.com pyblog/friday-qa-2016-02-19-what-is-the-secure-enclave.html commentshttp://www.mikeash.com/?page=pyblog/friday-qa-2016-02-19-what-is-the-secure-enclave.html#commentsmikeash.com Recent CommentsThu, 28 Mar 2024 14:46:13 GMTPyRSS2Gen-1.0.0http://blogs.law.harvard.edu/tech/rssP S - 2016-04-09 08:17:15http://www.mikeash.com/?page=pyblog/friday-qa-2016-02-19-what-is-the-secure-enclave.html#commentsWithout a replay protected memory no limitation on number of attempts can be enforced. There are a few options available. Embedded flash is very versatile, but adds extra masks and thus cost and is normally not used for processors but could be possible with the margins Apple have. Flash chips with replay protection and cryptographicaly tied to the processor is commonly used by mobile phones in the form of eMMC. It requires that you trust two chips though. If the NAND controller is not embedded in the NAND die depackaging attacks can allow replay. c5fb192fae3799454375369b578838deSat, 09 Apr 2016 08:17:15 GMTAlex Palacios - 2016-03-31 02:28:51http://www.mikeash.com/?page=pyblog/friday-qa-2016-02-19-what-is-the-secure-enclave.html#commentsExcellent article, did not know how the security enclave works. <br /> <br />It sounds very secure, the combination of: <br /> <br />UID + PASSCODE + SALT and the timers on failed attempts. <br />b9c0b860b1090f72f65569df96d993caThu, 31 Mar 2016 02:28:51 GMTFrancis Kim - 2016-03-31 02:09:03http://www.mikeash.com/?page=pyblog/friday-qa-2016-02-19-what-is-the-secure-enclave.html#commentsSo... apparently it's unlocked now, anyone know how they did it?729e3f2f2d0747950de254843932e2c1Thu, 31 Mar 2016 02:09:03 GMTMilton - 2016-02-29 10:29:58http://www.mikeash.com/?page=pyblog/friday-qa-2016-02-19-what-is-the-secure-enclave.html#commentsSecure Enclave is really a great security feature for Apple devices. <br /> <br />No one really knows if Apple can bypass it, because Apple's statements about this are not clear. <br /> <br />However, it's good to know that I'm safe, at least from third party users.9d42f17f30c9c24bf1883985da072283Mon, 29 Feb 2016 10:29:58 GMTZaph - 2016-02-26 22:29:42http://www.mikeash.com/?page=pyblog/friday-qa-2016-02-19-what-is-the-secure-enclave.html#commentsFrom Apple iOS Security Guide <a href="https://www.apple.com/business/docs/iOS_Security_Guide.pdf">https://www.apple.com/business/docs/iOS_Security_Guide.pdf</a> <br /> <br />Secure Element: The Secure Element is an industry-standard, certified chip running the Java Card platform, which is compliant with financial industry requirements for electronic payments. <br /> <br />Secure Enclave: On iPhone and iPad, the Secure Enclave manages the authentication process and enables a payment transaction to proceed. It stores fingerprint data for Touch ID.5cf0be8e71a7191686b90f0cf5c26614Fri, 26 Feb 2016 22:29:42 GMTmikeash - 2016-02-26 22:23:10http://www.mikeash.com/?page=pyblog/friday-qa-2016-02-19-what-is-the-secure-enclave.html#comments<b>Zaph:</b> I see the confusion. By "authorizing payments" I didn't mean communicating with the payment terminals. I merely meant that it is the one which manages the <i>user's</i> authorization to make a payment. The Secure Element handles the details with the NFC terminal, including making the authorization there. <br /> <br /><b>Kamil Borzym:</b> That's an interesting question. Perhaps TrustZone wasn't available early enough and Apple went their own way. Or perhaps it's ultimately less isolated from the rest of the system. I'm not familiar enough with it to say.224bcc15e22928a76901fb316fd5a367Fri, 26 Feb 2016 22:23:10 GMTZaph - 2016-02-26 22:15:54http://www.mikeash.com/?page=pyblog/friday-qa-2016-02-19-what-is-the-secure-enclave.html#commentsKamil Apple had to meet the requirements of the card issuers, they did not have a free hand. Being the first they were subjected to more requirements than latter entrants.ee1d8ae0964d221c30ec1fcfca3b6f6cFri, 26 Feb 2016 22:15:54 GMTZaph - 2016-02-26 22:11:50http://www.mikeash.com/?page=pyblog/friday-qa-2016-02-19-what-is-the-secure-enclave.html#commentsThe difference is "authorizing payments" is done by the Secure Element, the Touch ID is done by the Secure Enclave. Essentially the Secure Element is a crypto replacement for using the SIM card for payments. SoftCard was a payment method being pushed by the phone carriers (it was owned by three of them, later sold to Google) that used the SIM card and the Carriers would not allow any other entity to use them for payments. The option Apple took was to create the same SIM Card payment functionality in new Secure Element hardware. (Now other payment schemes are using HCE). I think that if you look at the Apple Pay documentation you will see the different functionality.227e3bf83c1b093d5d20dd8820638edfFri, 26 Feb 2016 22:11:50 GMTKamil Borzym - 2016-02-26 19:23:28http://www.mikeash.com/?page=pyblog/friday-qa-2016-02-19-what-is-the-secure-enclave.html#commentsHi! ARM architecture describes the TrustZone technology (<a href="http://www.arm.com/products/processors/technologies/trustzone/">http://www.arm.com/products/processors/technologies/trustzone/</a>). It describes separate virtual CPUs for trusted and non-trusted worlds, those CPUs running on one physical CPU. Starting from ARMv8, the TrustZone has full hardware support. Apple A7 is first ARMv8 based Apple CPU. Appearance of the Secure Enclave and a hardware based TrustZone coincides. Don't you think, that Apple could just use TrustZone as a backing for the Secure Enclave? If that is true, Apple would not need any additional physical CPU, and just run Secure Enclave kernel on the main CPU.92b59a694ece3a870ea97e228b5928dcFri, 26 Feb 2016 19:23:28 GMTmikeash - 2016-02-26 17:37:15http://www.mikeash.com/?page=pyblog/friday-qa-2016-02-19-what-is-the-secure-enclave.html#commentsFrom Apple's security guide, under "Apple Pay components": <br /> <br />"On iPhone and iPad, the Secure Enclave manages the authentication process and enables a payment transaction to proceed." <br /> <br />Both the Secure Element and the Secure Enclave participate.b67a70a2d75c6cd818ba3900f92303b4Fri, 26 Feb 2016 17:37:15 GMTZaph - 2016-02-26 17:32:17http://www.mikeash.com/?page=pyblog/friday-qa-2016-02-19-what-is-the-secure-enclave.html#commentsThe article contains the following: <br /> <br />"The Secure Enclave also handles Touch ID fingerprint processing and matching, and authorizing payments for Apple Pay." <br /> <br />But it is the Secure Element not the Secure Enclave that is used for authorizing payments for Apple Pay. <br /> <br />So the statement is at least to broad.5e2581e0f9f1b4cc0aa99896f0af6a9eFri, 26 Feb 2016 17:32:17 GMTmikeash - 2016-02-26 16:20:49http://www.mikeash.com/?page=pyblog/friday-qa-2016-02-19-what-is-the-secure-enclave.html#comments<b>Zaph:</b> That is true, but I'm not sure why you'd bring that up.2ba3e57c62873a43f2dc38a3c0b8c65dFri, 26 Feb 2016 16:20:49 GMTmikeash - 2016-02-23 20:38:22http://www.mikeash.com/?page=pyblog/friday-qa-2016-02-19-what-is-the-secure-enclave.html#commentsI don't think the Error 53 story has much to say here. The error itself was about a failure to authenticate the Touch ID hardware. It seems to confirm that the Secure Enclave software can in fact be updated, but we pretty much knew that already. The big question is how that update is implemented, and I don't think there are any clues about that.2fdd9784eaeeee2c39cfa5234129cba1Tue, 23 Feb 2016 20:38:22 GMTPentaprismatic - 2016-02-22 17:16:39http://www.mikeash.com/?page=pyblog/friday-qa-2016-02-19-what-is-the-secure-enclave.html#commentsDoes the software fix for Error 53 give you any more clues on how this works?dcd1a2aeabd8dc34660b3edebcd07bffMon, 22 Feb 2016 17:16:39 GMTmikeash - 2016-02-22 15:50:06http://www.mikeash.com/?page=pyblog/friday-qa-2016-02-19-what-is-the-secure-enclave.html#comments<b>Fred Fnord:</b> I still don't get it. I clearly don't think there <i>must</i> be a way to update the secure enclave without the passcode leaving data intact. I laid out the two possibilities in the article: either there are no checks and it leaves data intact, or there are checks and it wipes data. Which one is actually true is unknown. But it clearly can be updated without the passcode, since iPhones don't become un-updateable if you forget your passcode and wipe the device. So the question is just whether data wiping is enforced in that case. <br /> <br /><b>anurag:</b> Yes, that's the sort of thing you'd have to do. It's hard to estimate the difficulty, Apple's chips could be much harder to get into than that one, or much easier. In this particular case there's also the problem that you need to break into one particular device, not just any random iPhone. That means that your technique needs to be pretty reliable, because if you break the chip while trying to get into it, you're screwed.3a77e8835486649f0de000f1a2c67742Mon, 22 Feb 2016 15:50:06 GMTanurag - 2016-02-22 05:48:19http://www.mikeash.com/?page=pyblog/friday-qa-2016-02-19-what-is-the-secure-enclave.html#commentsSounds like "Trusted Platform Module" Can something like this will work against enclave, using electron microscope <a href="https://gcn.com/Articles/2010/02/02/Black-Hat-chip-crack-020210.aspx">https://gcn.com/Articles/2010/02/02/Black-Hat-chip-crack-020210.aspx</a>fa92612f275e556aa6c0e1feef013231Mon, 22 Feb 2016 05:48:19 GMTFred Fnord - 2016-02-22 00:52:23http://www.mikeash.com/?page=pyblog/friday-qa-2016-02-19-what-is-the-secure-enclave.html#comments"There has to be a way to update the phone without the passcode, otherwise the hardware becomes trash if you ever forget your passcode." <br /> <br />There has to be a way to erase the phone and set a new passcode without the passcode, but I don't see why there has to be a way to update the secure enclave software while leaving the data intact without the passcode. Obviously you do: what is it? <br /> <br />(This is why my response made no sense to you... obviously, I was completely mistaking your argument in the first place.) <br />479eb6f85028b456b7caf485b6f61fdeMon, 22 Feb 2016 00:52:23 GMTmikeash - 2016-02-21 21:34:52http://www.mikeash.com/?page=pyblog/friday-qa-2016-02-19-what-is-the-secure-enclave.html#comments<b>Fred Fnord:</b> There has to be a way to update the phone without the passcode, otherwise the hardware becomes trash if you ever forget your passcode. <br /> <br />I don't understand what problem your decrypt-then-reencrypt procedure is solving. If the user enters the passcode then the Secure Enclave can just update without wiping anything in the first place. The question is what happens if you try to update it <i>without</i> the passcode.ad04fe10078ed72e866c41950b02e0e4Sun, 21 Feb 2016 21:34:52 GMTFred Fnord - 2016-02-21 16:45:45http://www.mikeash.com/?page=pyblog/friday-qa-2016-02-19-what-is-the-secure-enclave.html#commentsI don't understand all this 'can they update it without wiping the iPhone' musing. <br /> <br />Let's say they have a good deal of confidence in their secure software, but not enough to make it automatically wipe your phone when updating. Why not just, when there is a secure enclave update, make the person authenticate, then decrypt their drive with the old software (perhaps writing it to the drive encrypted by the method that the 5c uses), then update, then reencrypt with the new? Sure, it will take a while, but it will not be too disruptive and it won't compromise security except while it is actually happening... and, given apps that can hold the iPhone unlocked for as long as they want, and given the apparently-quite-secure way the iPhone has of erasing flash after its data is deleted, I don't see this as inherently posing a security issue that isn't there already. e1a79e26c1ade916468238561b96df5cSun, 21 Feb 2016 16:45:45 GMTmikeash - 2016-02-21 16:32:56http://www.mikeash.com/?page=pyblog/friday-qa-2016-02-19-what-is-the-secure-enclave.html#comments<b>luiX_:</b> If you can upgrade the OS on a phone, you can wipe it regardless of the Secure Enclave's desires. You don't have to be able to decrypt data to be able to erase it. <br /> <br />They could prevent wiping the device without the passcode, but then you've made it so that forgetting the passcode permanently bricks your device.af6ee7b1ec6000bcf5abedb34aefc951Sun, 21 Feb 2016 16:32:56 GMTluiX_ - 2016-02-21 10:39:46http://www.mikeash.com/?page=pyblog/friday-qa-2016-02-19-what-is-the-secure-enclave.html#commentsBoth speculations have their own problem: <br /> <br />- Not deleting keys: security failure, makes brute force attack viable. <br />- Deleting keys: anyone can wipe your device. <br /> <br />Possibly, the first option is better for anyone who needs to hide some info, but the second one is worse for most of the people.227acb2cc60829471b535dbb15e1ff4eSun, 21 Feb 2016 10:39:46 GMTsigaba - 2016-02-21 03:19:18http://www.mikeash.com/?page=pyblog/friday-qa-2016-02-19-what-is-the-secure-enclave.html#comments<b>Jakob:</b> In theory, if all of the enclave's memory were encrypted with the same UID all the time, it's memory could be rewritten with a replay attack. Let's say the Enclave writes-out its keys, as encrypted data, to the filesystem. If this file were encrypted with the same UID each time, a malicious agent could copy that file and then rewind subsequent changes to the keys in the file, and the Enclave wouldn't have a way of knowing; the replayed file would look just like one it had created (this might allow someone to circumvent failed password back off intervals, or use an old password to unlock protected data, among other things). So, at the very least, the Enclave has to be able to keep a counter or nonce to mix with the UID, so replay attacks can't be done on it's Flash file. <br /> <br />It also needs enough memory to keep its own RTC, to prevent replays of saved RTC values interfering with things like password intervals and cert expirations. <br /> <br />This is all in a regime where you trust the Flash and RAM that's connected. It's completely possible that if the Flash (or the intervening kernel and APIs) are compromised, when the Enclave demands a key be deleted from the FS, the kernel simply lies to the Enclave, saying it does when it really doesn't. On an Apple device though the Boot firmware and the hardware configuration are signed by an Apply public key cert, and the Secure Enclave needs to do this validation (I think!), and it has to do it at a stage in boot when the Flash isn't available. (This is related to the whole Error 53 business. If the security infrastructure thinks a piece of its trusted hardware has been fiddled with during boot, it dumps out.)fd57bdb04ed264f45f29377894e1faecSun, 21 Feb 2016 03:19:18 GMTJakob - 2016-02-20 19:22:55http://www.mikeash.com/?page=pyblog/friday-qa-2016-02-19-what-is-the-secure-enclave.html#commentsWhy does the secure enclave need nonvolatile storage? Can't it just use its internal UID as a key to store whatever it wants encrypted on the phones' normal flash memory?ed449d050e4f7052471262b52aa8597cSat, 20 Feb 2016 19:22:55 GMTmikeash - 2016-02-20 15:42:26http://www.mikeash.com/?page=pyblog/friday-qa-2016-02-19-what-is-the-secure-enclave.html#comments<b>bob:</b> I see no problem with that approach in theory. In practice, this stuff is so tightly packed I'd bet it's hard to get access to the flash from outside without breaking the phone in some way. Resetting the timer probably means rebooting the phone which will also slow things down a lot. <br /> <br />There was actually an example of something like this from about a year ago: <br /> <br /><a href="https://www.intego.com/mac-security-blog/iphone-pin-pass-code/">https://www.intego.com/mac-security-blog/iphone-pin-pass-code/</a> <br /> <br />This takes advantage of a vulnerability where the phone didn't write out the information about the failed attempt right away, so by cutting power at just the right moment, it bypassed the artificial delay. This vulnerability has since been fixed. <br /> <br /><b> delay:</b> As you can see, a vulnerability like you describe did exist. I imagine they've fixed it now. Apple's guide actually mentions this briefly: <br /> <br /><div class="blogcommentquote"><div class="blogcommentquoteinner">On devices with an A7 or later A-series processor, the delays are enforced by the Secure Enclave. If the device is restarted during a timed delay, the delay is still enforced, with the timer starting over for the current period.</div></div> <br />I imagine it writes out information about the failure before reporting it back to the main CPU, so you can't know to cut the power until it's too late. <br /> <br /><b>kaw:</b> I'm not sure if you can get access to the AES engine normally. I'd assume you could access the one in the main CPU if you jailbroke. I don't think you could access the one in the Secure Eclave at all (barring a vulnerability in its code). <br /> <br />I'd be surprised if there were any duplicates. Even with bad randomness, it's more likely that they're all different, but more predictable. For an extreme case, imagine if the UIDs were just a counter starting from some random value. Totally predictable, but all unique, and impossible to detect from the outside. <br /> <br />And as you say, they could be random but the manufacturer could keep a list of all of them. <br /> <br />I'd love to know exactly how the UIDs are generated and written into the chips. I'd hope it uses some sort of inherently random physical process which doesn't require the information to exist outside the chip, but I really don't know. Because of it's very nature, we have to trust Apple and their chip suppliers that it works the way they say.4b0f8491f915367bfbaf924d26ee1ea3Sat, 20 Feb 2016 15:42:26 GMTkaw - 2016-02-20 10:41:46http://www.mikeash.com/?page=pyblog/friday-qa-2016-02-19-what-is-the-secure-enclave.html#comments<div class="blogcommentquote"><div class="blogcommentquoteinner">Each iOS CPU is built with a 256-bit unique identifier or UID. This UID is burned into the hardware and not stored anywhere else. The UID is not only inaccessible to the outside world, but it's inaccessible even to the software running at the highest privilege levels on the CPU.</div></div> <br />The premise of this security design is that these 256-bit UIDs are truly random (and nobody keeps a list that matches them to the phone's S/N). <br /> <br />Would it be possible to (indirectly) test their randomness by setting the passcode to e.g. "0000", encrypting some specific data with the hardware AES engine and then collect the encrypted data from <b>many</b> iPhones and check for duplicates? I, for one, would participate in such a test if there was an app for that. <br /> <br />Of course, if there are no duplicates the above mentioned list could still exist.0233a03419f5f0aca07a0b80ac303354Sat, 20 Feb 2016 10:41:46 GMTdelay - 2016-02-20 05:59:46http://www.mikeash.com/?page=pyblog/friday-qa-2016-02-19-what-is-the-secure-enclave.html#commentsHow is the delay on the SE enforced? If you try once, cut the power, then power it back on, does it forget you failed once? Thus you could try really quickly by powercycling the SE?cdf1453f089b3792878d5135c55f99c9Sat, 20 Feb 2016 05:59:46 GMTbob - 2016-02-20 03:42:27http://www.mikeash.com/?page=pyblog/friday-qa-2016-02-19-what-is-the-secure-enclave.html#commentsThe OS implements the minutes/hours delay + potential wiping setting on iPhone 5c. But where does the OS store this state? If there is no Security Enclave, what's to prevent someone with physical access to the chips on the phone from resetting the OS and its memory and starting over again every few attempts, to avoid the minutes/hours delay and prevent it from potentially wiping the phone?4d5b8a7d32c5d32fc47a54ee5eedfa71Sat, 20 Feb 2016 03:42:27 GMTmikeash - 2016-02-20 02:55:15http://www.mikeash.com/?page=pyblog/friday-qa-2016-02-19-what-is-the-secure-enclave.html#comments<b>vasi:</b> You're right, it would need its own nonvolatile storage in order to erase keys. It wouldn't need much, just 256 bits to store a master key. It wouldn't need to be very durable either, since it wouldn't be rewritten often. So it seems like it would be totally feasible, but I have no idea if the real thing actually has any. Using OS checksums as part of the key could help protect against outside attackers but wouldn't do anything against Apple, since they can just include the checksums from another version in their custom software build. <br /> <br /><b>ech:</b> That sort of hardware stuff is way outside my expertise, but speculation is fun, so.... I'd guess that it is absolutely possible, but the question is how much money it would cost. This is definitely not a weekend project for a couple of guys at the lab. You'd have to remove the packaging from the chip without destroying the guts, scan the chip to figure out where the UID is stored, then scan that area with an electron microscope. The individual components are 28 nanometers wide on the A7, and even smaller on newer ones, so everything is delicate and tiny. I wouldn't be surprised if the part that encodes the UID is somehow built to make it difficult to remove the packaging without destroying it. <br /> <br />There's some discussion about it here: <br /> <br /><a href="https://www.theiphonewiki.com/wiki/GID_Key">https://www.theiphonewiki.com/wiki/GID_Key</a> <br /> <br />That's mostly about the GID key, not the UID key, but the principle is the same. The GID key is another key baked into the hardware in a way that makes it difficult or impossible to retrieve, like the UID, but the GID is shared across all devices of a given model. <br /> <br /><b>asdf:</b> Apple's paper says they're using L4 but doesn't mention seL4. I have no idea if that's because they're not using seL4 or if that's just loose terminology. <br /> <br /><b>dkasper:</b> I saw that, and it's pretty convincing. I think there's still some room for key erasure when applying updates given that information. For example, the Secure Enclave could store a secure checksum of its firmware (again, assuming the SE has any of its own storage at all) and the hardcoded secure boot sequence could erase the master key (again, assuming there's storage in the SE) if the checksum doesn't match but the firmware still has a valid signature. But this is just a story I'm making up about how it could work, it says nothing about how it actually does. Right now I'm leaning towards the idea that it doesn't erase anything on update, but I'm still not sure.b3955dcc7f076bd17a6b6b08f20dc532Sat, 20 Feb 2016 02:55:15 GMTdkasper - 2016-02-19 23:39:11http://www.mikeash.com/?page=pyblog/friday-qa-2016-02-19-what-is-the-secure-enclave.html#commentsAccording to a former Apple security engineer it's likely that it can be updated without wiping the keys. <a href="https://twitter.com/JohnHedge/status/699892550832762880">https://twitter.com/JohnHedge/status/699892550832762880</a>6a27df2fdf11a8da99082ba5c4871478Fri, 19 Feb 2016 23:39:11 GMTasdf - 2016-02-19 22:09:48http://www.mikeash.com/?page=pyblog/friday-qa-2016-02-19-what-is-the-secure-enclave.html#commentsI remember reading something between speculation and a petition that Apple would replace Mach with L4 in OS X several years ago. Now I wonder if that was based on Apple research activity that ultimately became the Secure Enclave (or if some of those people got jobs at Apple and drove its adoption themselves). <br /> <br />Apart from the size, one interesting security feature of the seL4 implementation (which I assume Apple are using) is that the code has been formally proven correct.cefe6e6066be0357b242998936ef645eFri, 19 Feb 2016 22:09:48 GMTJon Bell - 2016-02-19 21:56:35http://www.mikeash.com/?page=pyblog/friday-qa-2016-02-19-what-is-the-secure-enclave.html#commentsThomas: <br /> <br />From what I've read, Android has nothing like this. If someone gets your device and they know what you're doing, they get everything. <br /> <br />There was a report a while back when some hacker-for-hire company had its data leaked. They said they could hack any Android or jailbroken iOS device ... but not a standard iOS device.18dd3a7f677954f267506beb60f69abdFri, 19 Feb 2016 21:56:35 GMTminh - 2016-02-19 21:22:37http://www.mikeash.com/?page=pyblog/friday-qa-2016-02-19-what-is-the-secure-enclave.html#commentsech, i pretty sure the UID is covered in epoxy, if you tried to open it to read the keys, the whole enclaved would be destroyed.7a5972460abc6e8c2b4067b8644ca26aFri, 19 Feb 2016 21:22:37 GMTech - 2016-02-19 19:09:16http://www.mikeash.com/?page=pyblog/friday-qa-2016-02-19-what-is-the-secure-enclave.html#commentsThere's been some speculation about using electron microscopes/etc to read the UID right off the chip to allow offline brute forcing. Do you think anyone is capable of doing that?8c07f457276a713b4e9689888c3a9851Fri, 19 Feb 2016 19:09:16 GMTThomas - 2016-02-19 18:15:58http://www.mikeash.com/?page=pyblog/friday-qa-2016-02-19-what-is-the-secure-enclave.html#commentsWhile everyone is talking about Apple hardware since that's what brought this whole conversation about, I'm wondering about Android users (let's not forget that Android represents the larger market share). Since there are hundreds of Android-powered phone models out there with many different hardware designs, it's a tricky conversation to have. Perhaps, though, we could focus for a moment on comparisons of modern hardware: if I'm buying a current-generation flagship (say, a Nexus 5x, Nexus 6p, or Samsung S6) I'm probably buying a phone that has something built on ARM's TrustZone technology (such as Qualcomm's SecureMSM/Haven or Samsung KNOX). How do these compare to Secure Enclave? Do they provide similar protections? Do they have similar vulnerabilities?0c50863d436678dffdb91a00506a333eFri, 19 Feb 2016 18:15:58 GMTvasi - 2016-02-19 17:53:40http://www.mikeash.com/?page=pyblog/friday-qa-2016-02-19-what-is-the-secure-enclave.html#comments<div class="blogcommentquote"><div class="blogcommentquoteinner">Secure Enclave could allow updates but delete the master keys</div></div> <br /> <br />Does the Secure Enclave contain some sort of secure non-volatile memory? If not, I'm not sure how it can delete something in a verifiable way. <br /> <br />I guess you could make the passcode hash dependent on both the passcode itself, the internal secure secret key, <b>and</b> some property of the current OS (eg: a checksum). Then when you do a software update, the Secure Enclave would have to recalculate the passcode hash...8d4e19018fa132c35e5fdf8c088a962aFri, 19 Feb 2016 17:53:40 GMT