I work on a vertical-market Mac application that uses a USB dongle to make sure users have paid for it. It's expensive enough, and in enough demand, that "black hats" have tried to crack the dongle scheme, so the app checks the executable and key resource files at runtime, and if something has been tampered with, the program won't run.
With PKI (Public Key Infrastructure) based code signing becoming more commonplace in the Mac world, I'm considering switching to using it to do this runtime verification, which would have the nice side effect of making Gatekeeper happy.
However, Apple's interest is very different from mine. Their focus is on making the user happy, so if an app has an incorrect signature, Mac OS X will simply ask the user if they want to run it anyway. My focus is on thwarting crackers, so if my app has an incorrect signature, I simply don't want it to do anything that's useful to an end-user.
So I want my app to be able to validate its own executable and resources, using Apple's signatures, at runtime.
Also, from what I've read of the libraries offered Mac OS X for doing validation, they simply give a "yes" or "no" answer to requests to validate an executable. It strikes me that this is susceptible to "black hat" attack in a number of ways - for instance, one could simply replace Apple's tools with ones that always say, "yes, this is valid", either in the system directories or by changing the search path for those tools. So I think it might be a good idea to build the complete set of signature validation code into my app.
So I have a few questions:
What PKI libraries/APIs are available to let an app validate its own executable and resources which have been signed using Apple's codesign system?
Do these libraries have source code available?
Are my security concerns about using the PKI libraries Apple ships with Mac OS X valid, or are they safer to use than I think?
Does anybody have experience with this kind of thing they'd be willing to share? Are there other gotchas or tips?
Thanks in advance for any help with this.
To answer #1 and #2 above, Apple has open-sourced its code for creating and verifying digital signatures as libsecurity_codesigning. So a developer could build that into their app to let it validate its own signature.
Alternatively, MacOS's version of this library can be used by an app - but the API is private, so that's a gotcha. There's a brief discussion at this link.
Related
I was wondering if it's possible to build a Mach-O file, or modify an existing one and then re-sign it so that the code sections will be encrypted.
I know that there's a flag called cryptid that represent the encryption type (by values `EncryptionInfo32/64 for load commands LC_ENCRYPTION_INFO_32/64 respectively)
However, I couldn't find anywhere in Xcode for how it's done.
EDIT : I'm well aware that it can be done in iOS, but my question relate to macOS, does the platform support this encryption feature in Mach-O file ?
EDIT2: So after reading the other question I understood that the whole encryption thing can only be done by appStore which is after the Mach-O file is already left the developer side. So in this case, Apple actually controlled the encryption/decryption algo+key and it's completely outside the developer hand, right ?
Also, since the Mach-O is being changed during the encryption, so who's in charge to re-sign the application ?
Thanks
No, you cannot do this.
The only "supported" way of getting LC_ENCRYPTION_INFO added to your binary is by distributing through the iOS App Store. It is Apple who checks your binary for compliance with their rules, then encrypts the binary and re-signs it.
This is all backed by "FairPlay", Apple's proprietary DRM stack. Not much is known about it since the code is heavily obfuscated, but it is widely believed that it's built on features of Apple's custom hardware AES engine. Given this, it may or may not be possible to create an encryptor yourself, but it would require immense reverse engineering efforts to even find out.
Further, the entire FairPlay stack is only present on Apple's own chips. It is indeed available on M1 Macs, as you can install iOS apps off the shelf (so long as you leave SIP enabled), but it is not available at all on Intel Macs (the relevant kexts are IOTextEncryptionFamily.kext and FairPlayIOKit.kext, the latter of which is obfuscated).
After reading through the extensive App Store guidelines (mac app store specifically), I've noticed a contradiction....
On one hand, under functionality, it clearly states:
2.7 Apps that download code in any way or form will be rejected
2.8 Apps that install or launch other executable code will be rejected
Yet when you read up further about purchase types, it often refers to in App Purchase 'downloads' and I'm pretty sure I remember reading in the bundle development guide (specifically plugin development) that these could be considered as in app purchases?
in 2.7 and 2.8 above, do they refer to code that they haven't checked i.e myAppPurchase.bundle which wasn't submitted at the app submission time, or is this concrete that absolutely NO bundles checked or unchecked by apple can be downloaded at all?
So in short, should an app be created in it's entirety i.e. with all the 'in app purchase extras' or can it be done modular i.e. an in app purchase downloads an approved bundle from the app store?
Cheers,
A
Although you can download content for in-app purchase, you aren't allowed to download code for later incorporation into the application. There are some theoretical edge cases, as you might have your own interpreter and might be able to download some amount of interpretable code in that case, you cannot download native code which will be executed either as part of the application (plugin) or an externally launched application.
As for the question of why Apple would cover this in the docs, it's likely because its the way that OS X and iOS apps are stored in the file system. Until Apple decides to allow downloadable binary executables, we're stuck using Plugin bundles in OS X only, ditto for non-OS framework bundles, which would arguably be even more useful. In particular, we have some bundles that are iOS/OSX cross-platform that we have to statically link under iOS, which is a shame.
Apple's apparent take is that if we can load code dynamically, then it is an opportunity to circumvent their review process by downloading an offending code module after the initial (or subsequent) program load. Imagine, for example, an application that talks to a server to download code which violates one of Apple's guidelines. If the version that is making the request has not yet been "released" by the malicious developer, no code is returned, and it just looks like it's checking in for an informative message of some kind. However, once Apple approves the App, the developer tells the server to start sending back a dynamic library, framework, or plugin which is then executed at the appropriate time by the now-malicious code.
The difficulty is that to prevent this from happening (through dyld or similar), you need to either whitelist everything that can be loaded, or you need to just prevent its use by application code altogether.
There's certainly the possibility that some kind of approved code whitelist could be used in the future, but until then, Apple has apparently chosen the route of just preventing the use of dynamic linking of non-system frameworks.
I've been asked to redesign our build/sign/release processes. I'm pretty happy with Windows stuff and I've identified several networked-HSM products that will do what we need. They basically integrate directly with CryptoAPI so the people doing the signing can just use signtool.exe as normal.
We currently have a separate Mac team who do their own build/sign/release. This is all working fine on a couple of Mac Minis in one of our DCs. I'd like to protect our Mac software keys as well and so I'm trying to find out how to integrate a networked-HSM into our Mac signing process.
I can't find any good information about this anywhere! So I'm hoping someone in here has done this already and can lessen my pain.
The actual questions are;
1) Can I use a HSM with the standard Mac code-signing tools?
2) Can anyone recommend a vendor/product for the above?
3) Can anyone point me towards some good documentation on Mac code signing and the inner-workings of the Mac crypto infrastructure?
Cheers
BHB
I don't believe any of the major HSM vendors (nCipher, SafeNet, etc.) have any hooks into the Mac code signing tools, nor do I believe Apple exposes any. Your best bet would be to try and determine what the code signing mechanism looks like when performed by the Mac tools and then try and duplicate it yourself manually. However, off the top of my head, I don't recall seeing that the major vendors support OSX-based HSM clients out of the box. I know that SafeNet supports Java via a custom JCE provider. If there's a PKCS#11 interface you can hook into, then you may be able to leverage OpenSSL or another similar toolkit, but it will result in some work for you.
I am developing an application in Flex using Adobe Flash Builder 4.5 and I want to distribute this as an AIR package so that it will work on multiple Operating Systems. I am wanting to target the usual suspects :-
Windows [what I currently develop on]
Apple [As I understand I need an actual Mac in order to package it] ?
Blackberry Playbook. [Again I believe I need the actual Playbook etc] ?
I also want to eventually deploy the application to the Mobile platform. So that also means targetting Android. Now as far as I am aware, and all research indicates this, I can develop my single application in Flash Builder 4.5 and then deploy to all these platforms. Am I correct in this?
Now to my real question. Obviously I am aware that the application needs to be digitally signed, so can I purchase ONE digital certificate to sign for ALL Operating Systems? The reason I am confused on this is because I know there is something I need to purchase from Apple ($99 per year reacurring) but is that just to distribute via iTunes network or is that a certificate as well ? Presuming it is, can I use said certificate for all the above platforms ?
As you can tell I am probably getting everything all crossed up and confusing myself LOL, so some help would be greatly appreciated.Regards Anthoni
EDIT:- Found this link [url]http://codesigning.ksoftware.net/[/url]
Apparently it is a Comodo code signing certificate and it lists the platforms as both Adobe AIR AND Apple. Has anyone experiance with this code certificate ?
Comodo certificates do work on all of the platforms you mentioned.
I develop a desktop application for use on Windows, and was wondering how I can get my executables signed so they stop showing those horrible looking warning messages about being from an unknown publisher. I am somewhat familiar with signing binaries before releasing them. I have a Linux port of the same program which is distributed though it's own signed repository (apt-get).
The process for signing windows executables seems extremely complicated and I can't find a simple tutorial on what to do, rather thousands of webpages describing only parts of the process, or which go into way too much depth.
I just need a quick list of steps which are necessary to sign executables under windows. I believe it's called "authenticode".
Tools see MSFT Introduction to Code Signing
edit: you buy a certificate from a provider - most web registrars sell them.
Then simply sign the executable using the msft tools
see http://www.instantssl.com/code-signing/code-signing-process.html