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.
Related
Maybe stupid question, but I can not find any good enough question. Currently I am defining some server configuration thru cloud-config as part of IaC idea. One part of configuration are also SSH public keys of server adminsitrators. My reason says this is public info and I should not worry too much to protect it, but I still want some extra confirmation.
So it is OK, security wise, to store (commit,push) public SSH keys in GIT repo?
There's no theoretical security problems to storing public keys in a repository. The conceptual idea of a public key is that it is known to everyone: the whole world knows it.
Now, as a practical matter, because a public key usually uniquely identifies a user, if someone gets ahold of that key, they may be able to correlate it with other locations where that user uses that key (e.g., GitHub, where all SSH keys are public) and decide that the user in question is an interesting target for phishing or other types of compromise based on correlating that user's usage.
This is one of those cases where the theoretical and practical security differs. Having said that, most people don't consider exposure of public keys a threat they have to deal with, and so checking them into a repository should be fine.
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.
Most of security guide say that Use of Hard-coded Cryptographic Key is dangerous because if cryptographic key in code is leaked to hacker, hacker can read encoding data used crypto algothrim (e.g. AES256)
so guide say that developer have to store cryptographic key outside source code. (like below pitcure)
enter image description here
but, i wonder it is safe that store cryptographic key outside source code?
let's suppose that cryptographic key is leaked to hacker, that mean hacker have got entire project source code because thare are no other way that can know cryptographic key in source code.
therefore although developer store cryptographic key in outside sourcode, it is dangerous
so my question is that
in web proejct is there any means of knowing cryptographic key stored in source code except way which get entire project source code?
In a web project, assuming I'm understanding what you're saying correctly, all of your code is private. You only output what you tell your server to output, and source code is inaccessible... unless someone really doesn't know what they're doing. Just make sure to use HTTPS to secure your cleint side, otherwise the whole World Wide Web could find out too.
Using a disassembler, most of your unique strings in any application are up for grabs. So are files, the best I know. Certificate pinning sounds close to what you're talking about, and I have modified a Snapchat APK to accept my certificate authority so I could perform a MITM on it. Trusting the CA on my phone wasn't enough, because the app had a not-so-easily defeated security feature. It only really works when either a.) a user wants to decrypt their own data, or b.) someone has way too much access to their phone.
This may be slightly outside of scope, but a good way to protect system function on the server side from abuse by your clients is to write an API for them to control their input precisely. Just food for thought.
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?
My client wants to encrypt/compress the html-code for their medical books in the iPhone bundle, to protect their IP.
Whats is a good way to prepare this file for the app bundle, and what complementary libraries (C, Obj-C) should I use to do the decryption and decompressing on the first launch of the app?
Copying the file to ~/Documents, then working on it seems like the best solution. Thoughts?
Here's a few thoughts.
If the book text is all alphanumeric data, then don't save the data as ASCII - save them in your own binary encoded format (for instance use 5 bits instead of 8 and pack into words). That gives you a bit of compression, slight obfuscation and a very cheap (in clock cycles) decompression. You would have a data format that is quick to access on the fly and will keep the casual curious hacker out of the text. Clock cycles would be my main concern and security second.
Another idea is store the decrypt key for a typical Blowfish encryption in obfuscated format in the app. Split into two or three constants that require some odd operation to restore for instance. But of course, now the overhead of Blowfish or whatever will be your concern.
Since you will not be able to implement perfect security (perfection is extremely expensive), the IP owners will have to use traditional copyright and trade secret techniques to fully protect their property. You've made it harder to hack, but it's still up to the lawyers to be diligent, just a book on the shelf in the reserved section of the library (no photocopies please!).
Cheers
This is quite tricky... almost impossible to make it really unbreakable. Any reasonnably motivated person will be able to pierce through it. You'll only make it a little harder to do. In any case, you definitely can't store any secret key in the bundle itself. You'd need to securely obtain the decryption key over a secure channel from a server and use it as needed. Even then, someone doing jailbreak would probably be able to run GDB over your running program and extract the secret key in RAM + the secret key would be shared amongst all users of your app... You're essentially trying to implement a DRM scheme, which is inherently flawed by design... Unless you need offline access, you might want to pull the data as needed from a secure erver... at least you "could" throttle information leakage...
I would keep the documents encrypted if I were you and just decrypt them as needed. One would easily be able to access the decrypted documents on a jailbroken device.
See the "Security Overview" document and the CryptoExercise sample code for encryption techniques
You probably won't like it, but the best way is to just not use HTML. Once you pass the decrypted HTML to UIWebView, it is very easy for a malicious user to steal it at that level, defeating any purpose your encryption algorithm had. A UIView subclass with custom drawing code and a custom encrypted backing format will be much more difficult to work around
From Mac OS X and iPhone OS Security Services:
You can use Keychain Services to
encrypt and store small amounts of
data (see Keychain Services Reference
and Keychain Services Programming
Guide). If you want to encrypt or
decrypt larger amounts of data in Mac
OS X, you can use the Common Security
Services Manager (CSSM) Cryptographic
Services Manager. This manager also
has functions to create and verify
digital signatures, generate
cryptographic keys, and create
cryptographic hashes. In iPhone OS,
the Certificate, Key, and Trust
Services API provides functions for
generating encryption keys, creating
and verifying digital signatures, and
encrypting blocks of data; see
Certificate, Key, and Trust Services
Reference.
It's always a choice between performance (encryption just doesn't come free) and security (security and everything else, really). But what else is new? If you keep the individual files small enough, maybe decryption doesn't slow you down much. Alternatively, you may consider predictive decryption such that you have certain files being decrypted in the background, say those linked from the currently viewed file, etc. I realize, however, that concurrancy on the iPhone may be pretty spotty (I don't know as I haven't dropped the cash for a license). You may also realize performance gains by only encrytping those files that really need it; does an index/table of contents or other often accessed file really need to be encrypted? Does that count as IP your client is worried about?
For compression I can recommend QuickLZ (fastest engine I saw, great compression ratio).