My team uses a certificate to sign our Windows Application. Unfortunately the Certificate is expiring soon and we need a new one.
We want to avoid the SmartScreen that pops up when installing apps signed with new certs and I am reading that EV Certificates come with built-in reputation.
Microsoft provides a list of authorities that sell code-signing certs, but from my understanding all of these would be a physical device that one of the devs would have to keep at their house.
We don't want that. Is it possible to have something on the cloud that we can all use?
Yes, it is possible to do EV code signing in the cloud without requiring a physical dongle that you keep with yourself. In fact, we do this at my company. Here is how:
Create the new signing key in a cloud-based HSM or KMS
Integrate your signing tool with the cloud-based HSM or KMS
For #1, there are several options including AWS CloudHSM, AWS KMS, Azure Key Vault, Google KMS, Entrust's nShield as a Service, Thales' DPoD, etc. They all have various pros and cons so you need to know your technical requirements ahead of time. Two items to definitely know are the list of signature algorithms the signing tools you use require and your CA's attestation requirements.
Some tools like signtool allow you to specify the hash algorithm you want to use. Unfortunately, other tools don't give you an option and you are stuck with the hardcoded hash algorithm. Two examples are Apple's productsign which currently uses SHA-1 under the hood for one of the signatures it produces and Microsoft's VBA Macro signing which uses MD5 under the hood. Not all of the KMS offerings support all these algorithms and, until they do, you would not be able to sign with those algorithms and your key wouldn't be useful (most only support SHA-256, SHA-384, and SHA-512, although Azure Key Vault does support RSNULL which allows you to get around this).
For key attestation, depending on your CA, you may need to provide an attestation for your key that chains up to a hardware root of trust, which only some of the HSM/KMS providers support. Other CAs may allow you to show them your cloud environment remotely (e.g., via Zoom or something) to show that the key is protected in hardware, and others just require you to sign a document stating that your key is protected.
Price is the next obvious factor. Some charge per hour (or other time unit) that the HSM is on, while most of the KMS options charge a small fee per key and per usage. Generally, if you only have a small number of keys, one of the KMS options will be the cheaper and easier choice. But once the number of keys grows, a dedicated HSM might become more cost effective.
After you pick your cryptographic device, you will need to integrate your signing tool with it. This is done with a cryptographic provider. Providers are unique to the platform you are signing on. For example, on Windows you need a KSP (or a CSP for legacy systems), Java/Android requires a JCE provider, macOS uses a CTK provider, OpenSSL uses the Engine framework (although that change in their latest release), Linux uses a mix of GPG and PKCS11, etc. Some HSMs provide some of the cryptographic providers, but not all. The KMS options don't have them at all and you're left writing your own code.
Then there is the issue of authentication/authorization, performance, auditing, and more. You will eventually find yourself in the boat where you want to auth/authz via your identity provider (e.g., Active Directory, Azure, etc.), you want client-side hashing to improve performance, you want all kinds of audit requirements, etc. For these reasons, and others, we use a tool called GaraSign for all of this which provides everything we need out of the box. Here's their code signing page.
SSL.com also provides remote signing for their EV Certificate. It's a paid service called eSigner.
We need a .cer so a 3rd party can validate our requests and responses. How do I go about getting one?
Your question is way too broad to be answered within StackOverflow.
If the other party has it's own requirements regarding what certificates must be used, then you need to follow that requirements. Also it's possible that this party issues certificates itself, in which case they will give you one.
If you are developing both sides of the communication, you can generate your own self-signed certificates and validate them.
Finally, if the other party has predefined trusted certificates or uses Windows trusted certificates, then you can use one of trusted / accepted CAs to get the certificate.
In general it's strongly recommended that you read a book or two about certificate basics - how they work and how they are used. For introductory material I can offer you the articles in our knowledgebase, they cover certificate basics and use of certificates for authentication.
I'm uploading a binary for the first time. iTunes Connect has asked me:
Export laws require that products containing encryption be properly authorized for export.
Failure to comply could result in severe penalties.
For further information, click here.
Does your product contain encryption?
I use https://, but only via NSURLConnection and UIWebView.
My reading of this is that my app doesn't "contain encryption," but I'm wondering if this is spelled out anywhere. "Severe penalties" doesn't sound pleasant at all, so "I think that's right" is a bit sketchy... an authoritative answer would be better.
Thanks.
UPDATE: Using HTTPS is now exempt from the ERN as of late September, 2016
https://stackoverflow.com/a/40919650/4976373
Unfortunately, I believe that your app "contains encryption" in terms of US BIS even if you just use HTTPS (if your app is not an exception included in question 2).
Quote from FAQ on iTunes Connect:
"How do I know if I can follow the Exporter Registration and Reporting (ERN) process?
If your app uses, accesses, implements or incorporates industry standard encryption algorithms for purposes other than those listed as exemptions under question 2, you need to submit for an ERN authorization. Examples of standard encryption are: AES, SSL, https. This authorization requires that you submit an annual report to two U.S. Government agencies with information about your app every January.
"
"2nd Question: Does your product qualify for any exemptions provided under category 5 part 2?
There are several exemptions available in US export regulations under Category 5 Part 2 (Information Security & Encryption regulations) for applications and software that use, access, implement or incorporate encryption.
All liabilities associated with misinterpretation of the export regulations or claiming exemption inaccurately are borne by owners and developers of the apps.
You can answer “YES” to the question if you meet any of the following criteria:
(i) if you determine that your app is not classified under Category 5, Part 2 of the EAR based on the guidance provided by BIS at encryption question. The Statement of Understanding for medical equipment in Supplement No. 3 to Part 774 of the EAR can be accessed at Electronic Code of Federal Regulations site. Please visit the Question #15 in the FAQ section of the encryption page for sample items BIS has listed that can claim Note 4 exemptions.
(ii) your app uses, accesses, implements or incorporates encryption for authentication only
(iii) your app uses, accesses, implements or incorporates encryption with key lengths not exceeding 56 bits symmetric, 512 bits asymmetric and/or 112 bit elliptic curve
(iv) your app is a mass market product with key lengths not exceeding 64 bits symmetric, or if no symmetric algorithms, not exceeding 768 bits asymmetric and/or 128 bits elliptic curve.
Please review Note 3 in Category 5 Part 2 to understand the criteria for mass market definition.
(v) your app is specially designed and limited for banking use or ‘money transactions.’ The term ‘money transactions’ includes the collection and settlement of fares or credit functions.
(vi) the source code of your app is “publicly available”, your app distributed at free of cost to general public, and you have met the notification requirements provided under 740.13.(e).
Please visit encryption web page in case you need further help in determining if your app qualifies for any exemptions.
If you believe that your app qualifies for an exemption, please answer “YES” to the question."
It's not hard to get approval for your app the proper way. SSL (HTTPS/TLS) is still encryption and unless you are using it just for authentication, then you should get the proper approval. I just received approval, and my app is in the store now for something that uses SSL to encrypt data traffic (not just authentication).
Here is a blog entry I made so that others can do this the proper way.
apple itunes export restrictions
Short answer: Yes, but you don't have to do anything
I was searching the web for this for some hours. Actually it is pretty easy and you can verify this in itunes connect:
1. All you have to do
If your app uses only HTTPS or uses encryption only for authentication, tokens, etc., there is nothing you have to do, just include
<key>ITSAppUsesNonExemptEncryption</key><false/>
in your Info.plist and you are done.
2. Verification
You can verify this in itunes connect.
select your app
chose features
chose encryption
click "+"
follow the dialog
for https or authentication the answer is yes and yes
In any case you should of course read yourself carefully through the dialog.
A very helpful article can be found here:
https://www.cocoanetics.com/2017/02/itunes-connect-encryption-info/
I asked Apple the very same question and got the answer (from a Sr. Export Compliance Specialist), that "sending information over https is forcing the data to go through a secure channel from SSL, therefore it falls under the U.S. Government requirement for a CCATS review and approval." Note that it doesn't matter that Apple has already done this for their SSL implementation, but for the government, if you USE encryption that is the same (to them) as you would've coded it yourself. I also updated our blog (http://blog.theanimail.com) since Tim linked to it with updates and details on the process. Hope that helps.
All of this can be very confusing for an app developer that's simply using TLS to connect to their own web servers. Because ATS (App Transport Security) is becoming more important and we are encouraged to convert everything to https - I think more developers are going to encounter this issue.
My app simply exchanges data between our server and the user using the https protocol. Seeing the words "USES ENCRYPTION" in the disclaimers is a bit scary so I gave the US government office a call at their office and spoke to a representative of the Bureau of Industry and Security (BIS) http://www.bis.doc.gov/index.php/about-bis/contact-bis.
The representative asked me about my app and since it passed the "primary function test" in that it had nothing to do with security/communications and simply uses https as a channel for connecting my customer data to our servers - it fell in the EAR99 category which means it's exempt from getting government permission (see https://www.bis.doc.gov/index.php/licensing/commerce-control-list-classification/export-control-classification-number-eccn)
I hope this helps other app developers.
If you use the Security framework or CommonCrypto libraries provided by Apple you do include crypto in your App and you have to answer yes - so simply because libraries were provided by Apple does not take you off the hook.
With regards to the original question, recent posts in the Apple Development Forums lead me to believe that you need to answer yes even if all you use is SSL.
As of September 20th, 2016, registering is no longer required for apps that use https (or perhaps other forms of encryption): https://web.archive.org/web/20170312060607/https://www.bis.doc.gov/index.php/informationsecurity2016-updates
In fact, on SNAP-R you can no longer choose 'encryption registration':
Specifically, they note:
Encryption Registrations no longer required – some of the information
from the registration now goes into the Supp. No. 8 to Part 742
report.
This means you may need to send an annual report to BIS, but you don't need to register and you can note when submitting your app that it is exempt.
Yes, according to iTunes Connect Export Compliance Information screens, if you use built-in iOS or MacOS encryption (keychain, https), you are using encryption for purposes of US Government Export regulations. Whether you qualify for an export compliance exemption depends on what your app does and how it uses this encryption. Attached images show the iTunes Connect Export Compliance Screens to help you determine your export reporting obligations. In particular, it states:
If you are making use of ATS or making a call to HTTPS please note that you are required to submit a year-end self classification report to the US government. Learn more
#hisnameisjimmy is correct: You will notice (at least as of today, Dec 1st 2016) when you go to submit your app for review and reach the Export Compliance walkthrough, you'll notice the menu now states that HTTPS is an exempt version of encryption (if you use it for every call):
I found this FAQ from the US Bureau of Industry and Security very helpful.
encryption
Question 15 (What is Note 4?) is the important point:
...
Examples of items that are excluded from Category 5, Part 2 by Note 4 include, but are not limited to, the following:
Consumer applications. Some examples:
piracy and theft prevention for software or music;
music, movies, tunes/music, digital photos – players, recorders and organizers
games/gaming – devices, runtime software, HDMI and other component interfaces, development tools
LCD TV, Blu-ray / DVD, video on demand (VoD), cinema, digital video recorders (DVRs) / personal video recorders (PVRs) – devices, on-line media guides, commercial content integrity and protection, HDMI and other component interfaces (not videoconferencing);
printers, copiers, scanners, digital cameras, Internet cameras – including parts and sub-assemblies
household utilities and appliances
Simple answers are Yes(App has encryption) and Yes(App uses Exempt encryption).
In my application, I am just opening my company's website in WKWebView but as it uses "https", it will be considered as exempt encryption.
Apple document for more info: https://developer.apple.com/documentation/security/complying_with_encryption_export_regulations?language=objc
Alternatively, you can just add key "ITSAppUsesNonExemptEncryption" and value "NO" in your app's info.plist file. and this way iTunes connect won't ask you that questions anymore.
More info: https://developer.apple.com/documentation/bundleresources/information_property_list/itsappusesnonexemptencryption?language=objc
You can follow these 3 simple steps to verify if your application is exempt or not: https://help.apple.com/app-store-connect/#/dev63c95e436
You may need to submit this annual-self-classification to US gov. For more info: https://www.bis.doc.gov/index.php/policy-guidance/encryption/4-reports-and-reviews/a-annual-self-classification
LOOKS LIKE HTTPS COUNTS
link to "Learn more":
https://www.bis.doc.gov/index.php/policy-guidance/encryption/4-reports-and-reviews/a-annual-self-classification
Just adding my personal interpretation of a very special case:
In my app the user has the option to go to a website themselves or let my app open Safari and Safari will call an HTTPS website. Could be any - own website, article etc etc. I interpret Safari making the actual HTTPS call, not my app and therefore answer the first question with No (or set the flag in the info.plist) and have no requirement to annually report.
If you're not explicitly using an encryption library, or rolling your own encryption code, then I think the answer is "no"
I am a developer working on several iPhone apps. I am an administrator in our Apple dev portal team. The Agent of our team is NOT a developer. I understand that ONLY the Agent can request an ad hoc deployment cert, and prepare an app for ad hoc distribution.
I assume that the Agent can generate the certificate and pass them to me so that I can provision and build the app for ad hoc distribution, but I have read horror stories about using multiple certificates in xCode. Just getting set up for development testing on the device was complicated enough!
Has anyone dealt with this issue? What pitfalls are there in using multiple certs in xCode? I suppose that I would also need to have the Agents public and private key in my keychain.
It's not a nightmare, it can just get a little confusing, especially if you give your profiles unhelpful names like "distribution profile." If you expect to have multiple sets of profiles, certificates, and keys on your computer, make sure they are named so that you know what goes with what and belongs with what.
I posted some recommendations in this area a while ago.
My number one piece of advice is to give your private keys descriptive names. Fortunately, you can do this at any time in Keychain Access. By default they are simply named "Private Key" and if you lose the certs you'll have to resort to some openssl geekery to figure out which key goes with which.
You are expected to use separate development and distribution certificates; you actually set up different configurations for them. The "nightmare" comes when you use several different development certificates. If anyone touches the certificate setting on the Debug configuration, it must thereafter be set manually (which is a pain in the ass, of course).
So no, there's no problem with the Team Agent giving you his distribution certificate and private key (you'll need both). He needs to realize that Apple will hold him responsible for your distribution of packages, though.
The main issue is that you'll need the Agent to export the private key they used to generate a certificate request for on the portal. The portal has instructions for backing up and transferring that private key... only when you have that key on your system can you make use of the certificates they create for Ad-Hoc.
The docs at this point for the whole process are pretty good, but you must read through them very, very carefully and follow eery step to the letter.