Hey, this is Kay from Privacy Engineering. I'm here to introduce a new and exciting Privacy and Security feature in Xcode that will help you automatically verify the integrity of your dependencies. At Apple, we believe that privacy should be at the core of everyone's development process, as much as it is at the core of our products. Dependency signature verification within Xcode will help app developers protect their apps and dependency authors protect the SDKs they distribute.

Apps are developed using a range of SDKs. For example, the iOS SDK. Some are made by Apple, some by app developers to use across all of their apps, and some that app developers obtain from other sources. These form the app's supply chain and can include frameworks, Swift source files, and other types of dependencies. Using third party SDKs can make app development significantly easier and can provide extended functionality. However, this does introduce risks.

Supply chain security is the process of mitigating these risks. You have the responsibility of protecting your users by being selective of what dependencies you include and to ensure that you don't accidentally use a version that has been maliciously modified. This responsibility also extends to SDK authors who include other SDKs as part of their development. The processes and tools available to mitigate these risks can be burdensome or complex to do manually.

Dependency signature verification is a new Xcode feature that can make this task easy and automatic. Now that you know what supply chain security is, I will talk about the role that digital signatures play in protecting developers and in helping reduce this burden. To begin, I will give you an overview on how Apple's code signing technology works and what Xcode now does to verify the signatures of your dependencies. And then I will talk about how app developers can use this feature to ensure that their dependencies haven't been compromised. And finally, I will discuss what SDK authors can do to improve the security of the ecosystem. I'll get started with how Apple's code signing technology works.

When you are developing an SDK for app developers to use, you want to ensure that no one can modify or tamper with it during its distribution to your SDK clients. Code signing is a mechanism to cryptographically link the final complied binary and the associated metadata such as the Info.plist or the privacy manifest for your framework or, for certain types of distribution, the source code itself, with your developer identity. At a high level, code signing works by first generating a Code Directory hash, also known as the CDHash, of your compiled binary.

To then sign this hash, you use your developer identity. This identity is represented by your developer certificate. It is made up of a private key that is used for code signing and a public key that is distributed as part of the signature. This signature can be tied back to your identity.

This identity is then used to sign the hash and can be combined with a secure timestamp that is used to validate that the signature was generated at a specific point in time. This ensures that if anyone tampers with your SDK, the signature will no longer be valid. It also allows app developers to verify that it was you who signed it, using the certificate that is embedded into the signature.

A common type of dependency that you may use in your app is the xcframework. With xcframeworks, the signature resides within the _CodeSignature directory. The code signature protects the integrity of all the files inside your final xcframework, including the privacy manifest files that are mentioned in the WWDC23 video "Get started with privacy manifests." It's possible for you to manually verify these code signatures for every version of every xcframework you include within your app, but this is a time-consuming process and places a burden on you in order to get the security benefits.

Signature verification is a new feature in Xcode that automatically handles the verification of your app's dependencies and protects your supply chain integrity by alerting you if an issue is detected. Xcode 15 now has tools to help you automatically track the identities used to sign any xcframeworks that you include in your project.

Xcode now shows a new section in the Inspector that displays the signature status for the xcframeworks you include within your app. This section includes information about the signature, such as the author's identity. It will show whether the xcframework is signed by an Apple Developer Program identity, signed by a self-signed certificate, or currently unsigned at all. In addition, Xcode will record the identity the first time you use the xcframework and verify that it does not change during later builds.

For different developer identities, Xcode provides differing levels of features based on the trust in the identity that was used for a particular xcframework. For Apple Developer Program identities, Apple is able to check the validity of the certificate used, including if it's been revoked, and ensure that multiple developers can't register with the same name. If the certificate used is self-signed, app developers should confirm its validity and authenticity directly with the dependency author.

When the xcframework author's signing certificate expires, Xcode is able to automatically validate that a new certificate for Apple Developer Program identities is from the same developer. For self-signed certificates, you will need to manually verify that this change was legitimate, as there is no attestation of the certificate by a trusted party, like Apple. When the dependency is signed by an Apple Developer Program identity, Xcode will verify it on build and show you an alert if the signature is not valid, the identity has changed, or the xcframework was signed after the certificate had expired.

Xcode will also alert you if the Apple Developer Program certificate has been revoked by Apple. This can happen if Apple determines that the developer account is malicious. These alerts will be rare and will automatically ensure you don't build your app until you've resolved the issue. If this does happen, Xcode will offer to let you remove the xcframework from the project. For self-signed identities, Xcode will still compare the certificate's SHA-256 fingerprint with the one that was previously added to the project. It will show you an alert if the identity has changed or if the contents of the dependency have been modified.

You may need to contact the xcframework author to ensure the fingerprint matches what they have used, or an xcframework author can publish this information. And that's how digital signatures work on xcframeworks. Next, let me show you how an app developer can use this feature in Xcode. To demonstrate, I'm going to use the Backyard Birds sample app. It provides a digital birding experience where you own multiple backyards, are able to put bird food and water out, and see when bird visitors show up.

I plan on using an xcframework called BirdFeeder to automate the food and water refilling process. The author of the BirdFeeder xcframework has signed the most recent release. Here, I've added the BirdFeeder into my project. For xcframeworks, Xcode 15 will have a "Signature" view in the Inspector. This displays the certificate signing information, showing the team details. The xcframework developer's identity will be stored in the project the first time it is seen. During the build, Xcode will validate that the identity used to sign the BirdFeeder xcframework matches the expected identity in the project. It built successfully.

To simulate a supply chain attack, I'll pretend that someone gave me an updated version of the BirdFeeder xcframework that they said added many new exciting features and gave better performance. This could also happen to you when you download an xcframework from a website that you do not fully trust. Here, I replaced my previous version with this updated one.

When I build my app, Xcode verifies the signatures of all the xcframeworks within the app. The build failed, pointing out that BirdFeeder developer's identity does not match what was previously recorded in the project. Selecting the error offers an alert explaining that the developer's identity has changed, showing how the expected identity compares to what is present in the new version. In this case, it shows that the expected certificate was an Apple Developer Program Certificate, but the one in the project uses a self-signed certificate.

This could mean that the xcframework has been compromised or the change was legitimate. For example, they might have transferred ownership of the xcframework to another developer. It's always safe to cancel if you're unsure. This gives you time to investigate if the change was genuine. Xcode protects you and your apps by ensuring that if this change happens, you will be notified automatically.

In this case, the change wasn't expected, so I will move this new version to trash in Xcode. However, if you know the change is legitimate– for example, the developer has communicated this to you via a verified public channel– then you could accept the change. Finally, I will talk about what this feature means to SDK authors.

It is important for SDK authors to cryptographically sign SDKs because it allows an app developer to confirm the identity and guarantees that the code has not been altered or tampered with after it was signed. Both of these properties are extremely important for building trust and safely distributing SDKs. As discussed earlier, there are two types of identity that you can use: Apple Developer Program and self-signed.

Members of the Apple Developer Program should use the certificates included as part of this program to ensure the trust of your SDK clients. You should use the Apple Distribution certificate if you publish your SDK or the Apple Development certificate if you are distributing test versions. Enterprise Program members should use their iOS Distribution or App Development certificates. When Apple issues a certificate to you, Apple is attesting to the fact that you are a legitimate member of the Apple Developer Program and have met all the necessary requirements to obtain the certificate.

This includes verifying your identity and adherence to Apple's policies and guidelines around privacy and security. If you manually revoke the certificate used to sign an SDK, you will need to release an updated version signed using a valid certificate, as Xcode will no longer be able to verify the signature when a developer attempts to build their app.

An SDK that has been signed with an Apple Developer Program certificate has a baseline level of trust and ensures that the SDK has not been tampered with. On top of that, because Apple is the trusted authority, certificate validation is automatically handled when a new certificate is generated. At the start of this video, I discussed how code signing works and how it includes a signature within your SDK using your developer identity. Let's now go through how you can do this using the codesign tool.

You can sign your xcframeworks using the command here and your Apple Developer Program identity. The timestamp flag is included to ensure that the signature contains a secure timestamp that is attested to by Apple. However, if you aren't a member of the Apple Developer Program, you can generate a self-signed certificate and use it with the codesign command.

You are responsible for sharing with your SDK clients the fingerprint of this certificate so that you can verify the xcframework was signed by you. Developers including your SDK in their app will be able to confirm that the xcframework was signed by you by using the new feature included in Xcode. If you always sign the SDKs you distribute, this new feature in Xcode will help your SDK clients get more confidence in their supply chain.

Doing this is simple. You can start straight away with versions of your frameworks that you've already published with no new build required. This even works using a self-signed certificate if you are not currently a member of the Apple Developer Program. You can then do this for all new versions of your xcframeworks by including the codesign command in a build script, so that you no longer need to worry. For app developers, Xcode 15 will automatically help you ensure the integrity and security of your apps' underlying SDKs. Making sure that all SDK signatures are verified is an important aspect of responsible app development and protecting your users.

You can help by encouraging the developers in your supply chain to start signing the SDKs they publish. For SDK authors, start signing your SDKs to ensure their security and authenticity. By signing your code, you establish trust with your SDK clients, showing them that you take their security and privacy seriously. Happy app development! This is Kay, signing off.