1Security White Paper For Purple v1 2================================== 3 4Author 5====== 6 7Michael Brouwer <mb@apple.com> 8 9 10Goals 11==== 12 13* SSL support with Client Side authentication working. 14* SecKeychain API for password storage. 15 16Footprint 17======= 18 19To get an idea of how small an SSL implementation can be I compiled 20MatrixSSL on ppc and arm. PPC binary is about 75k and arm is about 21100k. MatrixSSL uses a GPL license so we can't use it directly. 22However we could purchase a more liberal license from them and get 23additional features available in the commercial version only. I 24didn't investigate yet what those features are or what the pricing is. 25 26We've exceeded the matrixssl size by arriving at less than 100k ppc 27binary for sslv2 sslv3 tlsv1 support with aes rc4 3des md5 sha1 rsa 28support including the 40 bit export strength suites. 29 30I'm using the above numbers as a target to beat. Note that MatrixSSL 31only does SSLv3 and TLS. In addition it only supports a cipher suites 32using: MD2, MD5, SHA1, 3DES, and RSA. Also it doesn't support the 33weaker "export strength" algorithms, which use smaller (40 bit) key 34sizes, so you can't talk to an "export strength" only SSL server. 35 36Currently SecureTransport on Mac OS X supports, in addition to the 37above: SSLv2 and cipher suites using RC2, RC4, AES, and Diffie-Hellman 38key exchange (both anon and not). As well as export and non-export 39versions of everything. 40 41We can decide later on if we need the algorithms that we support above 42the MatrixSSL baseline, using a compile time flag. Of course each 43addition algorithm adds to the code footprint. Diffie-Hellman in 44particular adds extra code to SSL itself as well. Something else to 45consider is whether or not we want to support ECCDSA and SHA2 (256 384 46and 512) something that the Federal government is requiring. 47 48SSLv2 support is something else we need to decide whether or not we 49need, since supporting it requires a reasonable amount of code as 50well. It's generally considered insecure today, however I don't know 51how many websites are out there that only support SSLv2 and not any of 52the more modern protocols. If we decide it's worth dropping SSLv2 to 53save space, we should research this. 54 55SSL Milestones 56============ 57 58* Converted our existing SecureTransport SSL code to C from C++ (done) 59* Switch from using CDSA to embedded crypto (done) 60* Move to a standalone certificate verification layer (mostly done) 61 Once the above are completed we will have a functional standalone 62 SSL library without client side auth support. (done) 63* Optionally switch from using a generic ASN.1 encoding/decoding library to some 64 hand written C code instead which will be much smaller, saving and 65 estimated 100k code. (done) 66 67Progress 68======== 69 70I've started evaluating and collecting crypto algorithms for use with 71this SSL library. So far a number of them are smaller and faster than 72the ones provided with MatrixSSL. However this comparison was done on 73PPC as I don't have any ARM hardware to test on yet. Once selected 74these algorithms should probably also go into the IP-Sec stack in xnu 75or potentially even be shared between kernel and user space. 76 77Open Questions 78============== 79 80Do we need to support: 81 82* CRLs (could potentially be synced connected to a host computer) 83* OCSP certificate checking (requires a live connection). 84* Suite B algorithms: AES 128/192/256, SHA2 256/384/512 and 85 ECCDSA 256/384/512. 86 87MatrixSSL has no support for either. The federal government requires 88that we support at least one of the above and possibly even both. 89 90Keychain Support 91============== 92 93To add client side certificate support we will need a way to securely 94store private keys. For this I propose using a subset interface 95similar, or identical to, the current SecKeychain API, but with a 96completely new back-end implementation. This will get us both key and 97password storage at the same time. 98 99For the back-end we can either use sqlite3 as the data store layer or 100a custom lightweight DB or something based on CFPropertyLists. 101Tradeoffs are that sqlite3 will scale better to large numbers of items 102and large items (such as certificates and CRLs), but have a larger 103code footprint. Safari is probably the only client that doesn't 104already use sqlite3 though so in the other cases using sqlite3 will 105probably make the footprint smaller than having custom code. 106 107An alternative is to keep each type of item in a separate lightweight 108DB or property list to help scaling, but if a user stores a lot of web 109form passwords for a lot of websites we will still end up reading all 110of them into ram rather than just those we need when using sqlite3. 111 112In either case there need to be searchable attributes, and a single 113non searchable attribute per item which will be encrypted with a 114system wide key know only to a privileged agent. 115 116This agent will need to support 2 simple operations: encrypt blob and 117decrypt blob. The agent can live either in the kernel or in a 118lightweight server process that is launched on demand and can exit 119when it is no longer needed. In either case the agent guards the key 120bits but freely allows access to it by any client. This means we have 121no keychain ACLs and any application running on the system can decrypt 122all keychain secrets. Mac OS X currently has a much better 123architecture which allows unwrapping keys inside the agent and 124operating on them by reference without exposing the key bits to the 125client. For private keys and multi use sessions keys this might be 126desirable, but adds complexity and code size. 127 128Keychain Synching will require an agent running on the system that 129decrypts each item and re-encrypts it the way a Tiger system expects 130to see it. This can be done when the device is connect to a computer, 131by requiring the user to enter the synched keychain password on the 132device once to obtain the secrets. 133 134Other Security Issues 135===================== 136 137* I have not yet looked at SPNEGO and NTLM at all yet. 138* We might want to consolidate the Keychain secret mechanism above 139 with whatever the device will be using for music DRM services. 140 141Conclusion 142========== 143 144If desired I can turn this into a more formal whitepaper and 145start trying to set some milestones and timelines. However for now 146I'd like to get some feedback on the current plan. 147