WHITEPAPER

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