I've been included in an analysis project or "cleaning up" of information which includes fields from certificates. I don't know how to access the actual certificates. I'd like to learn as much as I can about how/what can be verified in relation to a certificate. (I'm not doing security work, I just need to read the information.)
I have several spreadsheets with information including certificate data, all different sources with different fields. I'm trying to consolidate this information into a single table with as much verified as possible. Most records have Control Name, Serial Number, URL, etc., but based on the inconsistencies throughout other fields I think wrong or incomplete data has been added.
For instance, I'd like to verify that the expiration date on a spreadsheet is what is actually on the certificate. It also looks like one of the spreadsheets converted long serial numbers into a numeric data type, truncating(all 0's) the last half of the SN. Is there a way to look up all of a CN's certificates issued by a CA?
I'm very new to this, any tips would be appreciated.
Thank you
There is no general, public way I know of.
However, you might be able to get in touch with some CAs and do a research cooperation, but I doubt it. Handing out certificates to somebody else could be a privacy concern. And there's no chance you'll get certificates from all the CAs out there.
What you can do is obtain the certificates when they are used for publicly available services. For example if a certificate is issued to mail.example.com you could try to establish a TLS session to the host. You may have to try different ports, and maybe you are lucky and the host presents the certificate you are looking for.
I need to open a CFStream socket connection to a server that has an untrusted CA root. I have the certificate of the server, and I can create a SecCertificateRef structure from it. The problem is how to set up the properties of the stream.
I think I should set the kCFStreamPropertySSLSettings property to a CFDictionary that in turn contains a kCFStreamSSLCertificates key. This key should hold a "a CFArray of SecCertificateRefs except for the first element in the array, which is a SecIdentityRef" according to the docs. Now I can create the SecCertificateRef from the server's certificate that I'll ship with the app, but how to get the SecIdentityRef? I guess it should be the client identity but I absolutely don't want client side authentication for now. And I can't find a way how to feed CFStream only with the server certificate.
Note, I don't want to add the untrusted certificate to the keychain, neither disable kCFStreamSSLValidatesCertificateChain in the settings. I need to accept the server authentication only if it is based on my own server certificate data loaded from the disk, and only on this CFStream.
I do not have the direct answer to your question, but perhaps few guidelines:
Why do you need to use the CFStream API and not the more intuitive NSURLConnection ?
From what I could find in the documentation, it seams like not everything that is available for Mac OS X, regarding CFStream API, is available for iOS. So think about it, and see if you can switch to NSURLConnection :-)
For NSURLConnection, you can use the NSURLConnectionDelegate methods to get the SSL challenge and validate the certificate on your own. You can check the wsdl2objc project, where I have implemented these features:
The project: http://code.google.com/p/wsdl2objc/
Some guidelines on how to get the certificate references: http://code.google.com/p/wsdl2objc/wiki/AdvancedOptions
Now about your questions :-)
I don't see how you can set a custom (untrusted) CA in kCFStreamPropertySSLSettings. I'm not sure if it can be done by using kCFStreamSSLCertificates since it is meant to be used for setting client-side certificates (thus the requirement of having the SecIdentityRef on index 0, which basically provides the private key).
When you say you don't want to add the certificate to the keychain, do you mean manually or programmatically ? I guess you don't like the users of your app to have to do it manually, but you can use the Security API to import the certificate programatically. In this case your certificate will be imported in a sandboxed keychain which is only available for your application. (again, not sure if this will work but worths the try)
In my applications I use NSURLConnectionDelegate to manually validate untrusted certificates.
Regards,
Pece
Basically you have to:
disable default trust evaluation using kCFStreamSSLValidatesCertificateChain
get the trust object (kCFStreamPropertySSLPeerTrust) once connected to the stream (but before sending any data, i.e, on kCFStreamEventCanAcceptBytes or kCFStreamEventHasBytesAvailable events)
set your self-signed root certicate as a trusted anchor for that trust object
optionally, you may add custom SSL policies to the trust object (e.g, hostname doesn't match certificate CN), but if you do that it's important that you do it before setting the trusted anchor or you may get kSecTrustResultRecoverableTrustFailure result
evaluate the trust object (SecTrustEvaluate) and check result is either kSecTrustResultProceed or kSecTrustResultUnspecified
On iOS, I know that we can evaluate a trust with SecTrustEvaluate(). To create a trust, we either import it from a *.p12 file or create it using an array of certificates and a set of policies.
I also know that in order to ensure that a server, that is not trusted by default, is trusted, we can use SecTrustSetAnchorCertificates() to augment the list of root CAs SecTrustEvaluate() uses to verify the server's certificate.
Now, how can I ensure that these anchor certificates are available on a subsequent launch? I can store certificates, keys and identities in the application keychain, but not a certificate chain. Even if I store all the certificates in the chain, how will I know what certificates are to be used as anchor certificates?
One solution that comes to mind is to just get all the certificates from the keychain and set them as anchor certificates. Another method could be to all the certificate chains on the disk as *.p12 files and load them once on every application run.
eskimo1 from Apple Devforums answered this so:
First up, you don't need to store the certificates in the keychain. You can store them elsewhere if you like (and create the SecCertificateRef using SecCertificateCreateWithData).
Secondly, your question talks about .p12 files, but I'm not sure what this has to do with things. In general you only use a .p12 file to distribute confidential information, and certificates are not confidential.
Finally, you can store a certificate chain by just storing the persistent reference to each certificate in that chain (or by storing the actual data of each certificate).
I am working on a e-banking iphone application.
I am using WSS with XML-Signature to sign the requests to the customer's SOAP server.
Since the iPhone device can not be trusted (due to jail-breaking), the customer
requirement is to manually encrypt the RSA key pair (using AES128) before storing the keys into keychain.
From what I have found so far, the keys are automatically added to the keychain when generated.
So my idea is to extract the data afterwards (the same way the public key is extracted in the CryptoExercise example), remove the keys from keychain, do the AES encryption and store it again into keychain as a custom NSData.
1) Do you see any problem with this ?
I read somewhere that retrieving the data or deleting the key might require some sort of password, although I didn't got what password. I will try this later today and will post the answer if no answer is posted in meantime :)
2) I can not find if there is any way to use this key without implementing some more hacks in the code?
It seams like the SecKeyRawSign method only accepts a SecKeyRef reference which is a pointer to the key in keychain. Is there some other method for signing using the NSData of the key ?
The only idea I have in the moment is to use SecItemAdd method to add the non-encrypted key into the keychain before signing, and remove it after signing. But I don't like this since it will happen all the time, and if the application is shut down (crashes or something) before the key is removed from keychain it will remain there until lets say the next time application is started.
Any idea for a better solution ?
regards
Consider checking Apple example and documentation for Security. Framework:
https://developer.apple.com/library/ios/#DOCUMENTATION/Security/Conceptual/CertKeyTrustProgGuide/iPhone_Tasks/iPhone_Tasks.html#//apple_ref/doc/uid/TP40001358-CH208-SW13 - see this link
Let's say I need to access a web service from an iPhone app. This web service requires clients to digitally sign HTTP requests in order to prove that the app "knows" a shared secret; a client key. The request signature is stored in a HTTP header and the request is simply sent over HTTP (not HTTPS).
This key must stay secret at all times yet needs to be used by the iPhone app.
So, how would you securely store this key given that you've always been told to never store anything sensitive on the client side?
The average user (99% of users) will happily just use the application. There will be somebody (an enemy?) who wants that secret client key so as to do the service or client key owner harm by way of impersonation. Such a person might jailbreak their phone, get access to the binary, run 'strings' or a hex editor and poke around. Thus, just storing the key in the source code is a terrible idea.
Another idea is storing the key in code not a string literal but in a NSMutableArray that's created from byte literals.
One can use the Keychain but since an iPhone app never has to supply a password to store things in the Keychain, I'm wary that someone with access to the app's sandbox can and will be able to simply look at or trivially decode items therein.
EDIT - so I read this about the Keychain: "In iPhone OS, an application always has access to its own keychain items and does not have access to any other application’s items. The system generates its own password for the keychain, and stores the key on the device in such a way that it is not accessible to any application."
So perhaps this is the best place to store the key.... If so, how do I ship with the key pre-entered into the app's keychain? Is that possible? Else, how could you add the key on first launch without the key being in the source code? Hmm..
EDIT - Filed bug report # 6584858 at http://bugreport.apple.com
Thanks.
The goal is, ultimately, restrict access of the web service to authorized users, right? Very easy if you control the web service (if you don't -- wrap it in a web service which you do control).
1) Create a public/private key pair. The private key goes on the web service server, which is put in a dungeon and guarded by a dragon. The public key goes on the phone. If someone is able to read the public key, this is not a problem.
2) Have each copy of the application generate a unique identifier. How you do this is up to you. For example, you could build it into the executable on download (is this possible for iPhone apps)? You could use the phone's GUID, assuming they have a way of calculating one. You could also redo this per session if you really wanted.
3) Use the public key to encrypt "My unique identifier is $FOO and I approved this message". Submit that with every request to the web service.
4) The web service decrypts each request, bouncing any which don't contain a valid identifier. You can do as much or as little work as you want here: keep a whitelist/blacklist, monitor usage on a per-identifier basis and investigate suspicious behavior, etc.
5) Since the unique identifier now never gets sent over the wire, the only way to compromise it is to have physical access to the phone. If they have physical access to the phone, you lose control of any data anywhere on the phone. Always. Can't be helped. That is why we built the system such that compromising one phone never compromises more than one account.
6) Build business processes to accommodate the need to a) remove access from a user who is abusing it and b) restore access to a user whose phone has been physically compromised (this is going to be very, very infrequent unless the user is the adversary).
The simple answer is that as things stand today it's just not possible to keep secrets on the iPhone. A jailbroken iPhone is just a general-purpose computer that fits in your hand. There's no trusted platform hardware that you can access. The user can spoof anything you can imagine using to uniquely identify a given device. The user can inject code into your process to do things like inspect the keychain. (Search for MobileSubstrate to see what I mean.) Sorry, you're screwed.
One ray of light in this situation is in app purchase receipts. If you sell an item in your app using in app purchase you get a receipt that's crypto signed and can be verified with Apple on demand. Even though you can't keep the receipt secret it can be traced (by Apple, not you) to a specific purchase, which might discourage pirates from sharing them. You can also throttle access to your server on a per-receipt basis to prevent your server resources from being drained by pirates.
UAObfuscatedString could be a solution to your problem. From the docs:
When you write code that has a string constant in it, this string is saved in the binary in clear text. A hacker could potentially discover exploits or change the string to affect your app's behavior. UAObfuscatedString only ever stores single characters in the binary, then combines them at runtime to produce your string. It is highly unlikely that these single letters will be discoverable in the binary as they will be interjected at random places in the compiled code. Thus, they appear to be randomized code to anyone trying to extract strings.
If you can bear to be iPhone OS 3.0-only, you may want to look at push notifications. I can't go into the specifics, but you can deliver a payload to Apple's servers along with the notification itself. When they accept the alert (or if your app is running), then some part of your code is called and the keychain item is stored. At this point, that is the only route to securely storing a secret on an iPhone that I can think of.
I had the same question and spent a lot of time poking around for an answer. The issue is a chicken and egg one: how to pre-poluate the keychain with data needed by your app.
In any case, I found a technique that at least will make it harder for a jailbreaker to uncover the information - they'll at least have to disassemble your code to find out what you did to mask the info:
String Obfuscation (if the link breaks search for "Obfuscate / Encrypt a String (NSString)")
Essentially the string is obfuscated before placed in the app, then you unobfuscate it using code.
Its better than doing nothing.
David
EDIT: I actually used this in an app. I put a base coding string into the info.plist, then did several operations on it in code - rot13, rotate/invert bytes, etc. The final processed string was used to decode the obfuscated string. Now, the three letter agencies could for sure break this - but at a huge cost of many hours decoding the binary.
I was going to say that this is the best technique I've come across, but I just read Kiran's post on UAObfuscatedString (different answer), which is a completely different way to obfuscate. It has the benefit of no strings saved anywhere in the app - each letter is turned into a method call. The selectors will show up as strings, so a hacker can quickly tell that your class used that technique though.
I think that this similar question, and my answer, may be relevant to your case too. In a nutshell, there was some talk of a trusted platform module being present in an iPhone. This would allow your service to trust an iPhone, even in the hands of an attacker. However, it looks like using the keychain is your best bet.
Did you consider/try the Push Notification suggestion, for initially transmitting the secret to the app & keychain? Or end up finding some other method to achieve this?
I'm going have my iphone app upload images to Amazon S3. Instead of putting the AWS credentials in the app, I am going to have the app phone home to my server for the URI and headers to use in the S3 upload request. My server will generate the S3 URI, proper signatures, etc. I can then implement a tighter, more specific security model on my app's webservice than AWS offers by itself and not give away my AWS keys to anyone with a jailbroken iphone.
But there still has to be some trust (credentials or otherwise) given to the app, and that trust can be stolen. All you can ever do is limit the damage done if someone jailbreaks an iphone and steals whatever credentials are in the app. The more powerful those credentials are, the worst things are. Ways to limit the power of credentials include:
avoid global credentials. make them per-user/application
avoid permanent credentials. make them temporary if possible
avoid global permissions. give them only the permissions they need. for instance, write permissions might be broken down into insert, overwrite, delete, write against resource group A or B, etc, and read could be broken into read named resources, read a list of all existing resources, read resource groups A or B, etc.
I would recommend creating a key at run time if possible. This way if the key were to get apprehended during a particular session, once the session ends, the key will be worthless. They could still apprehend the key from memory if they are smart enough, but it wouldn't matter since the key would become invalid after a period of time.
Sounds wonky. Would use HTTPS and maybe an encryption package to handle the key.
I think CommonCrypto is available for iPhone.
EDIT: Still sounds wonky. Why would anyone pass a secret key in an HTTP header? Anyone who traces your network traffic (via a logging wifi router, for instance) would see it.
There are well-established security methods for encrypting message traffic...why not use them rather than invent what is basically a trivially flawed system?
EDIT II: Ah, I see. I would go ahead and use the Keychain...I think it is intended for just these kinds of cases. I missed that you were generating the request using the key. Would still use HTTPS if I could though, since that way you don't risk people deducing your keygeneration scheme via inspection of enough signatures.