Dial M For Mitigation

493 views

Published on

A presentation of some of the security features and APIs in iPhone OS, allowing discussion of the threat model underlying Apple's chosen mitigation technology.

Published in: Technology, Education
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
493
On SlideShare
0
From Embeds
0
Number of Embeds
28
Actions
Shares
0
Downloads
7
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide
  • In this presentation we’ll look at some of the security mitigations in the iPhone OS, and try and determine what risks are being addressed. Ideally we’d work the other way round but we need to treat Apple’s threat model as a black box.
  • Rely on the fact that a signature can be generated with the private key (by decrypting the checksum), and verified with the public key (by encrypting the signature and comparing with the checksum). Then a certificate explains who the holder of the private key is. Next: what this means to an app
  • Rely on the fact that a signature can be generated with the private key (by decrypting the checksum), and verified with the public key (by encrypting the signature and comparing with the checksum). Then a certificate explains who the holder of the private key is. Next: what this means to an app
  • Rely on the fact that a signature can be generated with the private key (by decrypting the checksum), and verified with the public key (by encrypting the signature and comparing with the checksum). Then a certificate explains who the holder of the private key is. Next: what this means to an app
  • Rely on the fact that a signature can be generated with the private key (by decrypting the checksum), and verified with the public key (by encrypting the signature and comparing with the checksum). Then a certificate explains who the holder of the private key is. Next: what this means to an app
  • Rely on the fact that a signature can be generated with the private key (by decrypting the checksum), and verified with the public key (by encrypting the signature and comparing with the checksum). Then a certificate explains who the holder of the private key is. Next: what this means to an app
  • Rely on the fact that a signature can be generated with the private key (by decrypting the checksum), and verified with the public key (by encrypting the signature and comparing with the checksum). Then a certificate explains who the holder of the private key is. Next: what this means to an app
  • Rely on the fact that a signature can be generated with the private key (by decrypting the checksum), and verified with the public key (by encrypting the signature and comparing with the checksum). Then a certificate explains who the holder of the private key is. Next: what this means to an app
  • Rely on the fact that a signature can be generated with the private key (by decrypting the checksum), and verified with the public key (by encrypting the signature and comparing with the checksum). Then a certificate explains who the holder of the private key is. Next: what this means to an app
  • Rely on the fact that a signature can be generated with the private key (by decrypting the checksum), and verified with the public key (by encrypting the signature and comparing with the checksum). Then a certificate explains who the holder of the private key is. Next: what this means to an app
  • Rely on the fact that a signature can be generated with the private key (by decrypting the checksum), and verified with the public key (by encrypting the signature and comparing with the checksum). Then a certificate explains who the holder of the private key is. Next: what this means to an app
  • Rely on the fact that a signature can be generated with the private key (by decrypting the checksum), and verified with the public key (by encrypting the signature and comparing with the checksum). Then a certificate explains who the holder of the private key is. Next: what this means to an app
  • Rely on the fact that a signature can be generated with the private key (by decrypting the checksum), and verified with the public key (by encrypting the signature and comparing with the checksum). Then a certificate explains who the holder of the private key is. Next: what this means to an app
  • Rely on the fact that a signature can be generated with the private key (by decrypting the checksum), and verified with the public key (by encrypting the signature and comparing with the checksum). Then a certificate explains who the holder of the private key is. Next: what this means to an app
  • Rely on the fact that a signature can be generated with the private key (by decrypting the checksum), and verified with the public key (by encrypting the signature and comparing with the checksum). Then a certificate explains who the holder of the private key is. Next: what this means to an app
  • Rely on the fact that a signature can be generated with the private key (by decrypting the checksum), and verified with the public key (by encrypting the signature and comparing with the checksum). Then a certificate explains who the holder of the private key is. Next: what this means to an app
  • Rely on the fact that a signature can be generated with the private key (by decrypting the checksum), and verified with the public key (by encrypting the signature and comparing with the checksum). Then a certificate explains who the holder of the private key is. Next: what this means to an app
  • Rely on the fact that a signature can be generated with the private key (by decrypting the checksum), and verified with the public key (by encrypting the signature and comparing with the checksum). Then a certificate explains who the holder of the private key is. Next: what this means to an app
  • Rely on the fact that a signature can be generated with the private key (by decrypting the checksum), and verified with the public key (by encrypting the signature and comparing with the checksum). Then a certificate explains who the holder of the private key is. Next: what this means to an app
  • Rely on the fact that a signature can be generated with the private key (by decrypting the checksum), and verified with the public key (by encrypting the signature and comparing with the checksum). Then a certificate explains who the holder of the private key is. Next: what this means to an app
  • Rely on the fact that a signature can be generated with the private key (by decrypting the checksum), and verified with the public key (by encrypting the signature and comparing with the checksum). Then a certificate explains who the holder of the private key is. Next: what this means to an app
  • Rely on the fact that a signature can be generated with the private key (by decrypting the checksum), and verified with the public key (by encrypting the signature and comparing with the checksum). Then a certificate explains who the holder of the private key is. Next: what this means to an app
  • Rely on the fact that a signature can be generated with the private key (by decrypting the checksum), and verified with the public key (by encrypting the signature and comparing with the checksum). Then a certificate explains who the holder of the private key is. Next: what this means to an app
  • Rely on the fact that a signature can be generated with the private key (by decrypting the checksum), and verified with the public key (by encrypting the signature and comparing with the checksum). Then a certificate explains who the holder of the private key is. Next: what this means to an app
  • Rely on the fact that a signature can be generated with the private key (by decrypting the checksum), and verified with the public key (by encrypting the signature and comparing with the checksum). Then a certificate explains who the holder of the private key is. Next: what this means to an app
  • Rely on the fact that a signature can be generated with the private key (by decrypting the checksum), and verified with the public key (by encrypting the signature and comparing with the checksum). Then a certificate explains who the holder of the private key is. Next: what this means to an app
  • Rely on the fact that a signature can be generated with the private key (by decrypting the checksum), and verified with the public key (by encrypting the signature and comparing with the checksum). Then a certificate explains who the holder of the private key is. Next: what this means to an app
  • Rely on the fact that a signature can be generated with the private key (by decrypting the checksum), and verified with the public key (by encrypting the signature and comparing with the checksum). Then a certificate explains who the holder of the private key is. Next: what this means to an app
  • Rely on the fact that a signature can be generated with the private key (by decrypting the checksum), and verified with the public key (by encrypting the signature and comparing with the checksum). Then a certificate explains who the holder of the private key is. Next: what this means to an app
  • Rely on the fact that a signature can be generated with the private key (by decrypting the checksum), and verified with the public key (by encrypting the signature and comparing with the checksum). Then a certificate explains who the holder of the private key is. Next: what this means to an app
  • So that’s how the theory applies to an application. We sign all of the application content (on iPhone only; things change slightly on Macs due to the presence of dynamic libraries) so that even if an image or help file changes, we can detect it.
  • So that’s how the theory applies to an application. We sign all of the application content (on iPhone only; things change slightly on Macs due to the presence of dynamic libraries) so that even if an image or help file changes, we can detect it.
  • So that’s how the theory applies to an application. We sign all of the application content (on iPhone only; things change slightly on Macs due to the presence of dynamic libraries) so that even if an image or help file changes, we can detect it.
  • So that’s how the theory applies to an application. We sign all of the application content (on iPhone only; things change slightly on Macs due to the presence of dynamic libraries) so that even if an image or help file changes, we can detect it.
  • So that’s how the theory applies to an application. We sign all of the application content (on iPhone only; things change slightly on Macs due to the presence of dynamic libraries) so that even if an image or help file changes, we can detect it.
  • So that’s how the theory applies to an application. We sign all of the application content (on iPhone only; things change slightly on Macs due to the presence of dynamic libraries) so that even if an image or help file changes, we can detect it.
  • So that’s how the theory applies to an application. We sign all of the application content (on iPhone only; things change slightly on Macs due to the presence of dynamic libraries) so that even if an image or help file changes, we can detect it.
  • So that’s how the theory applies to an application. We sign all of the application content (on iPhone only; things change slightly on Macs due to the presence of dynamic libraries) so that even if an image or help file changes, we can detect it.
  • So that’s how the theory applies to an application. We sign all of the application content (on iPhone only; things change slightly on Macs due to the presence of dynamic libraries) so that even if an image or help file changes, we can detect it.
  • So that’s how the theory applies to an application. We sign all of the application content (on iPhone only; things change slightly on Macs due to the presence of dynamic libraries) so that even if an image or help file changes, we can detect it.
  • So that’s how the theory applies to an application. We sign all of the application content (on iPhone only; things change slightly on Macs due to the presence of dynamic libraries) so that even if an image or help file changes, we can detect it.
  • So that’s how the theory applies to an application. We sign all of the application content (on iPhone only; things change slightly on Macs due to the presence of dynamic libraries) so that even if an image or help file changes, we can detect it.
  • So that’s how the theory applies to an application. We sign all of the application content (on iPhone only; things change slightly on Macs due to the presence of dynamic libraries) so that even if an image or help file changes, we can detect it.
  • So that’s how the theory applies to an application. We sign all of the application content (on iPhone only; things change slightly on Macs due to the presence of dynamic libraries) so that even if an image or help file changes, we can detect it.
  • So that’s how the theory applies to an application. We sign all of the application content (on iPhone only; things change slightly on Macs due to the presence of dynamic libraries) so that even if an image or help file changes, we can detect it.
  • So that’s how the theory applies to an application. We sign all of the application content (on iPhone only; things change slightly on Macs due to the presence of dynamic libraries) so that even if an image or help file changes, we can detect it.
  • So that’s how the theory applies to an application. We sign all of the application content (on iPhone only; things change slightly on Macs due to the presence of dynamic libraries) so that even if an image or help file changes, we can detect it.
  • So that’s how the theory applies to an application. We sign all of the application content (on iPhone only; things change slightly on Macs due to the presence of dynamic libraries) so that even if an image or help file changes, we can detect it.
  • So that’s how the theory applies to an application. We sign all of the application content (on iPhone only; things change slightly on Macs due to the presence of dynamic libraries) so that even if an image or help file changes, we can detect it.
  • So that’s how the theory applies to an application. We sign all of the application content (on iPhone only; things change slightly on Macs due to the presence of dynamic libraries) so that even if an image or help file changes, we can detect it.
  • So that’s how the theory applies to an application. We sign all of the application content (on iPhone only; things change slightly on Macs due to the presence of dynamic libraries) so that even if an image or help file changes, we can detect it.
  • So that’s how the theory applies to an application. We sign all of the application content (on iPhone only; things change slightly on Macs due to the presence of dynamic libraries) so that even if an image or help file changes, we can detect it.
  • So that’s how the theory applies to an application. We sign all of the application content (on iPhone only; things change slightly on Macs due to the presence of dynamic libraries) so that even if an image or help file changes, we can detect it.
  • So that’s how the theory applies to an application. We sign all of the application content (on iPhone only; things change slightly on Macs due to the presence of dynamic libraries) so that even if an image or help file changes, we can detect it.
  • So that’s how the theory applies to an application. We sign all of the application content (on iPhone only; things change slightly on Macs due to the presence of dynamic libraries) so that even if an image or help file changes, we can detect it.
  • So that’s how the theory applies to an application. We sign all of the application content (on iPhone only; things change slightly on Macs due to the presence of dynamic libraries) so that even if an image or help file changes, we can detect it.
  • So that’s how the theory applies to an application. We sign all of the application content (on iPhone only; things change slightly on Macs due to the presence of dynamic libraries) so that even if an image or help file changes, we can detect it.
  • So that’s how the theory applies to an application. We sign all of the application content (on iPhone only; things change slightly on Macs due to the presence of dynamic libraries) so that even if an image or help file changes, we can detect it.
  • So that’s how the theory applies to an application. We sign all of the application content (on iPhone only; things change slightly on Macs due to the presence of dynamic libraries) so that even if an image or help file changes, we can detect it.
  • So that’s how the theory applies to an application. We sign all of the application content (on iPhone only; things change slightly on Macs due to the presence of dynamic libraries) so that even if an image or help file changes, we can detect it.
  • So that’s how the theory applies to an application. We sign all of the application content (on iPhone only; things change slightly on Macs due to the presence of dynamic libraries) so that even if an image or help file changes, we can detect it.
  • So that’s how the theory applies to an application. We sign all of the application content (on iPhone only; things change slightly on Macs due to the presence of dynamic libraries) so that even if an image or help file changes, we can detect it.
  • So that’s how the theory applies to an application. We sign all of the application content (on iPhone only; things change slightly on Macs due to the presence of dynamic libraries) so that even if an image or help file changes, we can detect it.
  • So that’s how the theory applies to an application. We sign all of the application content (on iPhone only; things change slightly on Macs due to the presence of dynamic libraries) so that even if an image or help file changes, we can detect it.
  • So that’s how the theory applies to an application. We sign all of the application content (on iPhone only; things change slightly on Macs due to the presence of dynamic libraries) so that even if an image or help file changes, we can detect it.
  • So that’s how the theory applies to an application. We sign all of the application content (on iPhone only; things change slightly on Macs due to the presence of dynamic libraries) so that even if an image or help file changes, we can detect it.
  • So that’s how the theory applies to an application. We sign all of the application content (on iPhone only; things change slightly on Macs due to the presence of dynamic libraries) so that even if an image or help file changes, we can detect it.
  • So that’s how the theory applies to an application. We sign all of the application content (on iPhone only; things change slightly on Macs due to the presence of dynamic libraries) so that even if an image or help file changes, we can detect it.
  • So that’s how the theory applies to an application. We sign all of the application content (on iPhone only; things change slightly on Macs due to the presence of dynamic libraries) so that even if an image or help file changes, we can detect it.
  • Identifying something is only useful if you’re going to ask questions about its identity. On the iPhone (and Mac) there’s a requirements language that lets you test properties of the developer’s identity and of the application. Applications have at least one requirement: the _designated_ requirement. Any code object that satisfies an app’s designated requirement is another version of that app, as far as the OS is concerned.
  • Identifying something is only useful if you’re going to ask questions about its identity. On the iPhone (and Mac) there’s a requirements language that lets you test properties of the developer’s identity and of the application. Applications have at least one requirement: the _designated_ requirement. Any code object that satisfies an app’s designated requirement is another version of that app, as far as the OS is concerned.
  • Identifying something is only useful if you’re going to ask questions about its identity. On the iPhone (and Mac) there’s a requirements language that lets you test properties of the developer’s identity and of the application. Applications have at least one requirement: the _designated_ requirement. Any code object that satisfies an app’s designated requirement is another version of that app, as far as the OS is concerned.
  • Identifying something is only useful if you’re going to ask questions about its identity. On the iPhone (and Mac) there’s a requirements language that lets you test properties of the developer’s identity and of the application. Applications have at least one requirement: the _designated_ requirement. Any code object that satisfies an app’s designated requirement is another version of that app, as far as the OS is concerned.
  • Identifying something is only useful if you’re going to ask questions about its identity. On the iPhone (and Mac) there’s a requirements language that lets you test properties of the developer’s identity and of the application. Applications have at least one requirement: the _designated_ requirement. Any code object that satisfies an app’s designated requirement is another version of that app, as far as the OS is concerned.
  • Identifying something is only useful if you’re going to ask questions about its identity. On the iPhone (and Mac) there’s a requirements language that lets you test properties of the developer’s identity and of the application. Applications have at least one requirement: the _designated_ requirement. Any code object that satisfies an app’s designated requirement is another version of that app, as far as the OS is concerned.
  • What you can’t see from this slide: the developer (D) and beta tester (B) must collude on production of the provisioning profile, and B can only produce a finite number of beta-test permissions for every app. It’s about 100. Also, Apple (A) adds DRM to the application before re-signing it and submitting it to the customer (C), so each app can be identified with the customer who purchased it. Before re-signing an application, Apple subjects it to a vetting process.

    Exercise: see if you can determine the routes malware authors will use to get their malicious software onto the phones of either B or C. How could these vulnerabilities be mitigated?
  • What you can’t see from this slide: the developer (D) and beta tester (B) must collude on production of the provisioning profile, and B can only produce a finite number of beta-test permissions for every app. It’s about 100. Also, Apple (A) adds DRM to the application before re-signing it and submitting it to the customer (C), so each app can be identified with the customer who purchased it. Before re-signing an application, Apple subjects it to a vetting process.

    Exercise: see if you can determine the routes malware authors will use to get their malicious software onto the phones of either B or C. How could these vulnerabilities be mitigated?
  • What you can’t see from this slide: the developer (D) and beta tester (B) must collude on production of the provisioning profile, and B can only produce a finite number of beta-test permissions for every app. It’s about 100. Also, Apple (A) adds DRM to the application before re-signing it and submitting it to the customer (C), so each app can be identified with the customer who purchased it. Before re-signing an application, Apple subjects it to a vetting process.

    Exercise: see if you can determine the routes malware authors will use to get their malicious software onto the phones of either B or C. How could these vulnerabilities be mitigated?
  • What you can’t see from this slide: the developer (D) and beta tester (B) must collude on production of the provisioning profile, and B can only produce a finite number of beta-test permissions for every app. It’s about 100. Also, Apple (A) adds DRM to the application before re-signing it and submitting it to the customer (C), so each app can be identified with the customer who purchased it. Before re-signing an application, Apple subjects it to a vetting process.

    Exercise: see if you can determine the routes malware authors will use to get their malicious software onto the phones of either B or C. How could these vulnerabilities be mitigated?
  • What you can’t see from this slide: the developer (D) and beta tester (B) must collude on production of the provisioning profile, and B can only produce a finite number of beta-test permissions for every app. It’s about 100. Also, Apple (A) adds DRM to the application before re-signing it and submitting it to the customer (C), so each app can be identified with the customer who purchased it. Before re-signing an application, Apple subjects it to a vetting process.

    Exercise: see if you can determine the routes malware authors will use to get their malicious software onto the phones of either B or C. How could these vulnerabilities be mitigated?
  • What you can’t see from this slide: the developer (D) and beta tester (B) must collude on production of the provisioning profile, and B can only produce a finite number of beta-test permissions for every app. It’s about 100. Also, Apple (A) adds DRM to the application before re-signing it and submitting it to the customer (C), so each app can be identified with the customer who purchased it. Before re-signing an application, Apple subjects it to a vetting process.

    Exercise: see if you can determine the routes malware authors will use to get their malicious software onto the phones of either B or C. How could these vulnerabilities be mitigated?
  • What you can’t see from this slide: the developer (D) and beta tester (B) must collude on production of the provisioning profile, and B can only produce a finite number of beta-test permissions for every app. It’s about 100. Also, Apple (A) adds DRM to the application before re-signing it and submitting it to the customer (C), so each app can be identified with the customer who purchased it. Before re-signing an application, Apple subjects it to a vetting process.

    Exercise: see if you can determine the routes malware authors will use to get their malicious software onto the phones of either B or C. How could these vulnerabilities be mitigated?
  • What you can’t see from this slide: the developer (D) and beta tester (B) must collude on production of the provisioning profile, and B can only produce a finite number of beta-test permissions for every app. It’s about 100. Also, Apple (A) adds DRM to the application before re-signing it and submitting it to the customer (C), so each app can be identified with the customer who purchased it. Before re-signing an application, Apple subjects it to a vetting process.

    Exercise: see if you can determine the routes malware authors will use to get their malicious software onto the phones of either B or C. How could these vulnerabilities be mitigated?
  • What you can’t see from this slide: the developer (D) and beta tester (B) must collude on production of the provisioning profile, and B can only produce a finite number of beta-test permissions for every app. It’s about 100. Also, Apple (A) adds DRM to the application before re-signing it and submitting it to the customer (C), so each app can be identified with the customer who purchased it. Before re-signing an application, Apple subjects it to a vetting process.

    Exercise: see if you can determine the routes malware authors will use to get their malicious software onto the phones of either B or C. How could these vulnerabilities be mitigated?
  • What you can’t see from this slide: the developer (D) and beta tester (B) must collude on production of the provisioning profile, and B can only produce a finite number of beta-test permissions for every app. It’s about 100. Also, Apple (A) adds DRM to the application before re-signing it and submitting it to the customer (C), so each app can be identified with the customer who purchased it. Before re-signing an application, Apple subjects it to a vetting process.

    Exercise: see if you can determine the routes malware authors will use to get their malicious software onto the phones of either B or C. How could these vulnerabilities be mitigated?
  • What you can’t see from this slide: the developer (D) and beta tester (B) must collude on production of the provisioning profile, and B can only produce a finite number of beta-test permissions for every app. It’s about 100. Also, Apple (A) adds DRM to the application before re-signing it and submitting it to the customer (C), so each app can be identified with the customer who purchased it. Before re-signing an application, Apple subjects it to a vetting process.

    Exercise: see if you can determine the routes malware authors will use to get their malicious software onto the phones of either B or C. How could these vulnerabilities be mitigated?
  • What you can’t see from this slide: the developer (D) and beta tester (B) must collude on production of the provisioning profile, and B can only produce a finite number of beta-test permissions for every app. It’s about 100. Also, Apple (A) adds DRM to the application before re-signing it and submitting it to the customer (C), so each app can be identified with the customer who purchased it. Before re-signing an application, Apple subjects it to a vetting process.

    Exercise: see if you can determine the routes malware authors will use to get their malicious software onto the phones of either B or C. How could these vulnerabilities be mitigated?
  • What you can’t see from this slide: the developer (D) and beta tester (B) must collude on production of the provisioning profile, and B can only produce a finite number of beta-test permissions for every app. It’s about 100. Also, Apple (A) adds DRM to the application before re-signing it and submitting it to the customer (C), so each app can be identified with the customer who purchased it. Before re-signing an application, Apple subjects it to a vetting process.

    Exercise: see if you can determine the routes malware authors will use to get their malicious software onto the phones of either B or C. How could these vulnerabilities be mitigated?
  • What you can’t see from this slide: the developer (D) and beta tester (B) must collude on production of the provisioning profile, and B can only produce a finite number of beta-test permissions for every app. It’s about 100. Also, Apple (A) adds DRM to the application before re-signing it and submitting it to the customer (C), so each app can be identified with the customer who purchased it. Before re-signing an application, Apple subjects it to a vetting process.

    Exercise: see if you can determine the routes malware authors will use to get their malicious software onto the phones of either B or C. How could these vulnerabilities be mitigated?
  • Keychain, or a similar API, exists on other platforms but in the case of the iPhone the private key is baked into the device rather than being derived from a password. What does that mean for the confidentiality of the keychain items? What about when the phone is backed up using iTunes?
  • Each application has space for its documents, library files (prefs and support files), cache/scratch files and confidential data. But no application can work with the files of any other, and access to system files is limited to public API. Why should Apple put this restriction in? What benefits does it provide?
  • Each application has space for its documents, library files (prefs and support files), cache/scratch files and confidential data. But no application can work with the files of any other, and access to system files is limited to public API. Why should Apple put this restriction in? What benefits does it provide?
  • Each application has space for its documents, library files (prefs and support files), cache/scratch files and confidential data. But no application can work with the files of any other, and access to system files is limited to public API. Why should Apple put this restriction in? What benefits does it provide?
  • Each application has space for its documents, library files (prefs and support files), cache/scratch files and confidential data. But no application can work with the files of any other, and access to system files is limited to public API. Why should Apple put this restriction in? What benefits does it provide?
  • Each application has space for its documents, library files (prefs and support files), cache/scratch files and confidential data. But no application can work with the files of any other, and access to system files is limited to public API. Why should Apple put this restriction in? What benefits does it provide?
  • Each application has space for its documents, library files (prefs and support files), cache/scratch files and confidential data. But no application can work with the files of any other, and access to system files is limited to public API. Why should Apple put this restriction in? What benefits does it provide?
  • Each application has space for its documents, library files (prefs and support files), cache/scratch files and confidential data. But no application can work with the files of any other, and access to system files is limited to public API. Why should Apple put this restriction in? What benefits does it provide?
  • Each application has space for its documents, library files (prefs and support files), cache/scratch files and confidential data. But no application can work with the files of any other, and access to system files is limited to public API. Why should Apple put this restriction in? What benefits does it provide?
  • Each application has space for its documents, library files (prefs and support files), cache/scratch files and confidential data. But no application can work with the files of any other, and access to system files is limited to public API. Why should Apple put this restriction in? What benefits does it provide?
  • Each application has space for its documents, library files (prefs and support files), cache/scratch files and confidential data. But no application can work with the files of any other, and access to system files is limited to public API. Why should Apple put this restriction in? What benefits does it provide?
  • Each application has space for its documents, library files (prefs and support files), cache/scratch files and confidential data. But no application can work with the files of any other, and access to system files is limited to public API. Why should Apple put this restriction in? What benefits does it provide?
  • Each application has space for its documents, library files (prefs and support files), cache/scratch files and confidential data. But no application can work with the files of any other, and access to system files is limited to public API. Why should Apple put this restriction in? What benefits does it provide?
  • Each application has space for its documents, library files (prefs and support files), cache/scratch files and confidential data. But no application can work with the files of any other, and access to system files is limited to public API. Why should Apple put this restriction in? What benefits does it provide?
  • Each application has space for its documents, library files (prefs and support files), cache/scratch files and confidential data. But no application can work with the files of any other, and access to system files is limited to public API. Why should Apple put this restriction in? What benefits does it provide?
  • Each application has space for its documents, library files (prefs and support files), cache/scratch files and confidential data. But no application can work with the files of any other, and access to system files is limited to public API. Why should Apple put this restriction in? What benefits does it provide?
  • Each application has space for its documents, library files (prefs and support files), cache/scratch files and confidential data. But no application can work with the files of any other, and access to system files is limited to public API. Why should Apple put this restriction in? What benefits does it provide?
  • Each application has space for its documents, library files (prefs and support files), cache/scratch files and confidential data. But no application can work with the files of any other, and access to system files is limited to public API. Why should Apple put this restriction in? What benefits does it provide?
  • Each application has space for its documents, library files (prefs and support files), cache/scratch files and confidential data. But no application can work with the files of any other, and access to system files is limited to public API. Why should Apple put this restriction in? What benefits does it provide?
  • Each application has space for its documents, library files (prefs and support files), cache/scratch files and confidential data. But no application can work with the files of any other, and access to system files is limited to public API. Why should Apple put this restriction in? What benefits does it provide?
  • Each application has space for its documents, library files (prefs and support files), cache/scratch files and confidential data. But no application can work with the files of any other, and access to system files is limited to public API. Why should Apple put this restriction in? What benefits does it provide?
  • Feel free to contact me and ask any questions.
  • Feel free to contact me and ask any questions.
  • Feel free to contact me and ask any questions.
  • Feel free to contact me and ask any questions.
  • Feel free to contact me and ask any questions.
  • Feel free to contact me and ask any questions.
  • Feel free to contact me and ask any questions.
  • Feel free to contact me and ask any questions.
  • Feel free to contact me and ask any questions.
  • Feel free to contact me and ask any questions.
  • Dial M For Mitigation

    1. 1. Dial M for Mitigation Graham Lee
    2. 2. Code Signing - Identity Private Key Public Key
    3. 3. Code Signing - Identity Private Key Public Key
    4. 4. Code Signing - Identity Private Key Public Key
    5. 5. Code Signing - Identity Private Key Public Key
    6. 6. Code Signing - Identity Private Key Public Key
    7. 7. Code Signing - Identity Private Key Public Key
    8. 8. Code Signing - Identity Private Key Public Key
    9. 9. Code Signing - Identity Private Key Public Key 50f4b5a228b18a0c55747daee6f09c3800773b14
    10. 10. Code Signing - Identity Private Key Public Key
    11. 11. Code Signing - Identity Private Key Public Key
    12. 12. Code Signing - Identity Private Key Public Key 50f4b5a228b18a0c55747daee6f09c3800773b14
    13. 13. Code Signing - Identity Private Key Public Key 50f4b5a228b18a0c55747daee6f09c3800773b14 50f4b5a228b18a0c55747daee6f09c3800773b14
    14. 14. Code Signing - Identity Private Key Public Key
    15. 15. Code Signing - Identity Private Key Public Key
    16. 16. Code Signing - Identity Private Key
    17. 17. Application Signing MyGreatApp.ipa
    18. 18. Application Signing MyGreatApp MacOS Contents Resources NIBs, images… MyGreatApp.ipa
    19. 19. Application Signing MyGreatApp NIBs, images… MyGreatApp.ipa
    20. 20. Application Signing MyGreatApp NIBs, images… MyGreatApp.ipa
    21. 21. Application Signing MyGreatApp NIBs, images… MyGreatApp.ipa
    22. 22. Application Signing MyGreatApp NIBs, images… MyGreatApp.ipa
    23. 23. Code Signing - Requirements MyGreatApp.ipa
    24. 24. Code Signing - Requirements MyGreatApp.ipa
    25. 25. Code Signing - Requirements MyGreatApp.ipa
    26. 26. Code Signing - App Store A B C D
    27. 27. Code Signing - App Store A B C D
    28. 28. Code Signing - App Store A B C D
    29. 29. Code Signing - App Store A B C D
    30. 30. Code Signing - App Store A B C D
    31. 31. Code Signing - App Store A B C D
    32. 32. Code Signing - App Store A B C D
    33. 33. Keychain Services • Passwords • Certificates • Private Keys • Data blobs
    34. 34. Keychain Services • Passwords • Certificates • Private Keys • Data blobs
    35. 35. Sandbox
    36. 36. Sandbox /tmp
    37. 37. Sandbox /tmp
    38. 38. Sandbox /tmp /tmp
    39. 39. Sandbox /tmp /tmp /tmp
    40. 40. iamleeg
    41. 41. iamleeg

    ×