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.
Related
I am building an iPhone app, and I currently need to encrypt a string, store it in a file and be able to decrypt it later. As I understand, I can use symmetric encryption to do this but my key for encryption/decryption can be reversed-engineered. Assymetric encryption can solve this problem but it seems I would need a server to send the data to decrypt with the private key. Does anyone know of a way I can encrypt/decrypt the string securely in a stand-alone app?
Thanks!
As with all matters concerning security, the question is: who are you defending against?
If you are trying to prevent the casual thief (or script kiddie) from reading an encrypted string, using the built-in iOS cryptographic services, such as the Keychain, can provide adequate-to-good security. Obviously the strength of the security will hinge in part on various factors beyond your control (notably, what sort of password lock, if any, the user has configured for the device).
The next level up would be symmetric encryption using a symmetrically encrypted key (i.e. one protected by a user passphrase). As #lukas noted, of course in principle this can be cracked, but from a practical standpoint if the user chooses a sufficiently strong passphrase for a sufficiently large key, a casual to intermediate-level attacker will be effectively thwarted.
If, on the other hand, you need to keep secrets, as Bruce Schneier would say, not from your kid sister but from major world governments, these approaches are likely to be insufficient, and you will have to explore other options, including but not limited to storing the string in multiple locations, using multiple keys, and multiple factors of authentication.
The lead Apple reference for all this (save the last option) is the Secure Coding Guide, which has references at the end of the opening page to the other more specific programming guides (covering, e.g., the Keychain and Cryptographic Services). I also heartily recommend Graham Lee's Professional Cocoa Application Security. If you want a theoretical foundation, the gold standard is Schneier's Applied Cryptography.
This basic question is asked pretty constantly on Stackoverflow. The answer is that you cannot obfuscate yourself to security against your own customers, and you should never spend excessive money trying. I recommend the following links to find the many previous discussions:
Best practices for iOS applications security
Secure https encryption for iPhone app to webpage
From the above you will find several more links. But the final answer is that you are likely trying to solve the wrong problem, and the problem you think you want to solve is unsolvable.
Does anyone know of a way I can encrypt/decrypt the string securely in a stand-alone app?
No. If someone have the physical access to the data it can be cracked. Make a webservice to solve the problem.
Have you considered using Keychain Services?
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.
We have a code-signing certificate, purchased from GlobalSign for Authenticode signing (as they call it). Now we need to sign Java applet and soon Adobe AIR module (applet?). The question is: from technical point of view is there any difference between certificate-for-Authenticode and certificate-for-Java or certificate-for-AIR, if they are issued by the same CA (say Comodo or GlobalSign)? I don't see a point in buying different certificates if they are replaceable.
I understand that key usage field of certificates must be the same (code signing), but maybe extended code usage or policy or other extension differs in those certificates. I would appreciate if somebody who has code-signing certificates of two or more types issued by one CA could check this for me.
There's an explicit statement at http://www.adobe.com/devnet/air/articles/signing_air_applications.html that:
"A developer can use any class-3,
high-assurance certificate provided by
any CA to sign an Adobe AIR
application."
Unfortunately, I can't find anything similar for Java. However, regardless of the minimum certificate requirements for the various platforms, your best bet might be to contact your existing certificate provider to ask if there are any meaningful differences between the certificates they offer for these platforms.
Some of the blah-blah on the Verisign website suggests that the format in which the certificate is delivered to the purchaser is the only real difference between their offerings, but they don't actually state this directly, so who knows...?
From what I gather from RFC 5280, the key usage extensions can only decide whether the certificate is usable for code signing or not. There doesn't seem to be anything in the RFC that can constrain whether you sign Java code or AIR or whatever. This seems to imply that if you can sign one piece of code (or any other kind of non-key data) you can sign any.
That said, there may be CA-specific extensions in your certificate. Without seeing the certificate it's hard to tell if there are limitations.
From a technical perspective, as long as the client (i.e. the browser if we're talking about applets) recognises the CA and is happy with your combination of key usage and certificate type (DIGITAL_SIGNATURE and OBJECT_SIGNING) then you should be fine.
It seems that any code signing certificate will work for any mentioned platform. I asked GlobalSign support about the difference - they didn't respond, however soon after that they have changed their web page and now you would be buying one code signing certificate for all platforms.
What's the canonical way to manage cryptographic keys associated with particular source code? (e.g. SSH or RSA key pairs strongly associated with a particular program).
I am reluctant to check this into version control for obvious reasons, but I don't want them to reside only on few people's local hard drives either.
You could put them into version control encrypted, and let only a few people know the password. This has the advantage that they are stored along with the code and that you can update them easily, but the files are useless to an attacker (providing you use a strong password).
The industrial-strength answer is to use a Hardware Security Module (HSM).
The slightly less fancy answer is to keep a printed and/or electronic copy in the company safe.
Very good question and there's no absolute right answer IMO.
Questions to ask yourself:
1) What's the impact of a key becoming known
2) What is the trust level in the company
3) How important is it for engineers to be able to produce release builds
Ideas I have used over the years include:
Stored in source control repository but with restricted 'secure_group' access
Pros
Key proliferation is reduced
Access permissions are controlled by
scm admins
Cons
Release build is restricted to those
with secure permissions
Requires implicit trust of secure group members
Keys injected by build system
Standard build contains dummy key(s).
Release builds are generated by build server which replaces or injects production keys
Pros
No bottleneck on engineers when
building code
Key management is
restricted to build server + admins
Cons
- All data/systems must support dummy key
- Build server becomes bottleneck/mission critical component
Custom DRM package
Create your own key package i.e. RSA encrypted header with session generated symmetric key to encrypt key data. DRM approach also allows you to do stuff like set package expiry time or maximum number of uses
Pros
Keys can be encapsulated
Keys can
be safely distributed
Audit trail as key package is generated per user
on demand with pub/private key pair
Cons
- A lot of custom code
- All build systems need to be re-engineered to read key package data
- Key Package needs lib/API to extract and so engineer can still read key data
There are other options such as secure encryption server or two-pass authentication web sites to retrieve key data.
In my experience there is no perfect solution though I'd be very interested in hearing suggestions or opinions from the community
Hope that helps
When I was in charge of managing our software signing keys, I kept the GPG key on two hosts on our network with excellent host security and good firewalls. I burned two CD copies: one for our CTO, and one for our CEO. (I just told him, "Do not lose this disc. Do not give it away." Keep it simple. :)
The passphrase for the key was different. I remembered that. The coworker who would fill in for me if I was missing knew the passphrase. I asked our CEO and CTO to keep the passphrase well away from the CD with the key.
Of course, this was for keys that we would use at most once in a day, and often not for days or weeks at a time, when we released security updates. If your needs are different than ours were, you might need to do something else.
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.