 So, I see a lot of new faces, who I have not met before. Can I see a series of hands? The new faces who don't know me before? Okay. So, there's a lot of background about me. As you know, I'm currently in the mobile platform team in SDG Joe. And today I'm going to talk about iOS core signing horror. The earlier title that I put, iOS core signing, even though nobody would tell you, I thought it's a little bit strong. So, I'm going to change the title to this. But, okay. This is a little bit today. I'm going to learn about core signing in general and iOS core signing and look at individual components of core signing and how they fit together. You might have pressed upon all these things while building an app or while going through the process of core signing, but there are some interesting things that I'm going to say. Again, there is a background about me. So, I've been building iOS as for almost 10 years now. I started pretty much from the beginning of iOS SDK. So, iOS dev scout is actually my name. So, I started iOS dev scout in 2011 then. For the last two years, maybe in all of those, they were taking care of me quite well. So, you haven't seen me for almost one year plus. Then, I am with Melvin and few others, organized iOS conference in Singapore. The next one is going to be in January. And, I sometimes write articles on their own. Again, talking about why you should care for core signing, who hasn't seen this app before. So, if you have been developing iOS as for a few years, you might have seen this, where your core signing schools are, then you have this little button called fix issue with the blue color. It's very tempting to click, but the moment you click on this, something schools up and a lot of people complain. A lot has been put over the past. But again, this is from Felix, the creator of Aslan. Is core signing a real problem? Yes, a lot of people fix it day-to-day. Even after the improvement of automated core signing, the underlying concepts are still the same. And this is very strong, and it says, iOS developers don't understand core signing properly. That is because you don't deal with it every day. You just write code. You write in suite. And a lot of time, you just know how to fix a problem, but how it works, you rather, more than half of the time, the developers don't really understand how core signing really works. So, while you make core signing, this topic was signature in general. You sign on different things on a day-to-day life, contracts, house agreements, offer later any legal document. So, this ensures that the signing part is someone real, and it's a trusted person. It's not someone like a foster, or somebody sitting in Nigeria or signing on behalf of you. So, this is what a signing does. The core signing for software is specifically similar. It says that software has been signed by a legitimate developer, not necessarily a good developer, but a legitimate developer. So, your software might have bugs, but this is someone who is just an entity can verify. And the software has not been modified or corrupted since the time it is signed. So, that's what core signing is all about. And iOS core signing basically ensures that every app available on App Store are from legitimate developers. Developers who have paid $99 per year and Apple knows them and ask one sign by this developer is not being modified by somebody in the train. And also, if it lets Apple to control what software or what point it can be installed in which iOS devices. The first thing you do is you create a certificate signing request. You create a certificate signing request with a certificate of authority. It usually involves creating a public key and private key, so I'm going to talk about it in a while. It contains your information, like email, country, signature, etc. And most of the time, you use the teach and app to create the CSR file. But let's look into what's under the CSR file. If you use the open SSL command line tool then you can see what this particular CSR file contains. You can see there's the email of the person, there's the name, the country, and the algorithm has been used to create a CSR file. And if you see the texture and the presentation of this file then you can see there's this public key that is part of the CSR file. A lot of this thing happens under it. You don't even realize that the public key is created, the private key is there. But this is what happens in the very first step in the CSR file. And creating a certificate. Now there are ten different types of certificates that are available there. A lot of these things do different things. Certificate is the development certificate and production certificate. Now you can see the program system file. Apple verifies this from you. Then it keeps you a certificate. And you can, again, see this certificate as your name, the e-supername, which in this case is Apple Inc. And basically this is the certificate that you will use to sign your code. There is this file. The moment you install, explore, do so with this, after you download the certificate or you install the certificate, but this file is there. Now what does this file do? This Apple WordWord, WordWire, you have a permission in terms of your certificate. So the certificate is this certificate in that it verifies all of the certificate in your kitchen, our bank certificate. It's not fit by somebody. So it's an intermediate certificate that ensures the authenticity of all of the certificates in your kitchen. Now if you have multiple machines between which you need to kind of save these keys, then you export your certificates using this file called PKGrid. PKGrid does it stores your private key with the certificate. It has containers called savepads. And these bags have their own attribute and contain. For other certificates, we have one bank certificate and another one got a private key. There are few more things which are post-writing, one is a team ID, one is a bundle ID, one is app ID, device ID and documents. Let's look into each one of them. The team ID is unique ID for each development team. You might be part of multiple development teams. So in each development team, you have a unique ID. Bundle ID identifies a particular app. The app ID is a combination of your team ID and bundle ID. And your device ID is the unique identifier of a device, which is a 14-liter digit number. The entertainment is basically the capability of the application that supports it. Within the app ID, you can put an explicit app ID or wildcard app ID. So the wildcard app ID could have something like the reverse token name or the asterisk. Then with this particular certificate you can build any bundle identifier that matches with this particular wildcard ID. But there will be some limitations. There are some good services that you won't be able to use if you use the wildcard app ID. This is the meat of your co-standing producing profile. It binds all your things when you talk about your certificate, your CSR, your app ID and the devices. It's really easy to create multiple provisioning profiles for the same certificate. And if you do so, it's going to make your life hard. If you have all these provisioning profiles in your machine and in a non-certificate expire, then you are basically going to spend a lot of time debugging what is happening. This is the number of provisioning profiles I have on my machine which is not a good sign. I have about 132 profiles. Some of them might be expired. But what export does I'm going to do it uses this command line called code sign. It uses a certificate and once you clear the boundary, it uses the boundary to sign the app. Three steps. It has something called signature and it has a signature and it has a code requirement. So what is it? So the code sign generates a sign by running different parts of your code. The app has a solution of every part of your code and the verify uses the same passing algorithm to verify that this code is listed and it has not been modified. It tells the signature on the other hand that it is not the signature of the message. It creates the digital signature using the private key and the sign has this in the app along with the sign of the certificate to predict the digital signature. So if your app is legitimate and you want to earn the verify code on the code sign you should see something like write on this and satisfy the requirements. Now let's look into something in front. Are you able to power any app from App Store and sign with your own certificate and tell that this app is printed by you? This is an app called File Browser. I don't know who built this. Of course, none of you in this audience can want to re-sign a popular app. So what it does is as you know your IPA files are nothing but a compressed file and just convert it to a chip then you can see the payload of this IPA and once you look at this you can see bunch of things. Now this is where if your app is something in your 100 rupee group you might swap here but what do you want to do here? I have all the things that I've written here as a certificate I'm just going to re-sign this app and it's basically a sign using my own certificate. Can I install this app on my device? I re-signed using my own certificate at this point no because there is some additional way of security that you need to remove before you can even install and use this app. This re-signing means that if I submit this app on App Store Apple will know that this app is not me. It's not from somebody else. So again the what you can do with this knowledge is the same. So once you kind of have all the all the things all the dots join then you can understand how re-signing works then the next time when you see something goes up you can go a little bit better in Q2 given the comments and there are actually various tools available by Fastman himself to manage these things. One of the tools Natch what Natch does is it it helps you store these certificates and provisioning profiles in a Q2 group so that anyone in your team they can just use Fastman command and they have required profiles and request certificates they do not need to create new certificates against new profiles. So I'm going to show one more thing the issues that we face. So what's going to happen is like we have as you saw that we have a lot of provisioning profiles and like SP we have SP to this app or whatever but we also have a lot of internal apps there that SP employees use and some other stakeholders use. So the internal apps are signed by the enterprise certificate so you use the enterprise certificate to sign the apps and when you use the enterprise provisioning profile there's an expired period for this provisioning profile and even now it's one year for this profiles to expired and Apple sends email to the admins when the profiles are due to be expired. So one of the popular apps that we have been working on so it the profile expired and the apps suddenly stopped working and you just were basically really upset about it. So what we do after that we use another command which is fastly specific so this is a Ruby script what it says is if we log in on behalf of you it will download all the provisioning profiles and it will check the validity of this profile so I'm just going to run the command so you work it out see all these profiles are due to be expired within a month another few original things that we have done here one is the notification part application that we send to Slack then we send this notification to the required developers by email as well so it's not just one person who is going to receive the notification from Apple that this profile is expired but the whole team will know that this profile is actually expired in one month or six months and then you can do something about it so that's it for my presentation any questions some questions anyone in the team can accept is there any security so for the development certificate there is no security issue for that so you again you can create a team team development certificate and then you can share it among the developers and there is no security implications for that but if your team members have access to the apps to distribution certificate then you usually the bigger organization it goes to a DevOps team so the developers are not supposed to raise the apps themselves so it goes to a DevOps process that you should be careful about who has the key to the distribution certificate what happens if you submit the private app to the app store so again so this app itself just the first signing part works I would imagine Apple would have some other checks to catch the authenticity of that app I have never tried that but yeah maybe we should try it now any questions yes I am just going to give a speech on our maintenance work as a personal project of mine that I launched yesterday as a platform for mentors and mentees so if you are interested you can check it out the two categories that I have launched with for now is for women take and startups I am going to launch more categories in future but it is a soft launch for now and yeah thank you