On segunda-feira, 26 de setembro de 2016 22:36:18 PDT Greg Zaverucha wrote: > 1. The thread below mentions using platform crypto libraries like CNG, and > platform (D)TLS implementations. A crypto library usually only implements > primitives like Encrypt, Sign, Verify and not higher level protocols like > TLS. These can be considered separately. We could, for example, > - use mbedtls for the (D)TLS implementation and modify it to call a platform > specific crypto library like CNG or OpenSSL for the underlying crypto > operations. > - use a platform specific (D)TLS implementation, e.g., OpenSSL > on Linux or SChannel on Windows. These usually use the platform's crypto > implementation. (e.g., SChannel calls CNG, and OpenSSL is both a TLS > library and a crypto library).
Given the option, I'd prefer using the full transport layer library if one exists. We shouldn't be implementing DTLS or TLS, if we can avoid it. The least amount of security code we have to maintain, the best for us. That said, we have a very specific case of DTLS without encryption needed for onboarding. We need to check if that is possible with the platform implementations. > 2. Do we have to provide something for bare-metal platforms (or OSes that > don't include crypto/TLS)? If so, we need to keep mbedtls/tinydtls support > for them. In AllJoyn OpenSSL(Linux) and CNG(Windows) are supported, and > there is also a "built in" option that included crypto implementations for > bare metal systems. It's my understanding that OpenSSL has a relatively > large code footprint compared to something like mbedtls (purpose-built for > embedded systems), so making it a required dependency may have performance > implications. You know my opinion on Arduino. Given that I want to drop it from IoTivity main implementation, the answer is only whether full-fledged OSes provide the APIs we need. We may stumble on Android, but I think OpenSSL is enough there. IoTivity-Constrained is another matter. It can provide an mBedTLS integration, but in fact that's one that definitely needs to be integrated with whatever the OS provides. Given that there's a need for encryption at the link layer, it's highly likely that a device will have some crypto library available. This becomes an issue for porting to that OS. > 3. Does certificate parsing & manipulation happen in IoTivity or > OpenSSL/CNG/mbedtls. (do you consider certificate functions as part of > crypto) Currently, I don't think we need access to the certificate during normal operations. For Security 2.0, we may need access to some information found in the certificate, but that can probably be abstracted away. I just hope we don't need to write an ASN.1 parser... The question is what happens during onboarding. Do we perform a regular CSR?certificate signing like a CA? Or is our protocol different? Also, the device needs to generate its private keys when onboarding. Note: I'm not including the requirements of the Onboarding Tool itself. > 4. Writing an abstraction layer for specific crypto primitives like > ECDSASign is pretty easy. The AllJoyn source has an example, and interop > issues at the crypto layer were very rare. Abstracting a platform (D)TLS > implementation may be more difficult and lead to more interop bugs. Also, > TLS has a rich set of versions, options, extensions and ciphersuites, and > we'll find different subsets of them are supported in different > implementations. Assuming the current subset is usable for IoTivity, going > forward changes to how TLS is used may be blocked by this. (and it's > something the OCF Security WG would also have to consider, before, e.g., > spec'ing that a particular TLS extension be used) Agreed. OCF should specify the minimum ciphers and extensions to be supported, as well as blacklisted ciphers and extensions (e.g., TLS compression). The decision on which ones those are is out-of-scope for now, though the WG/TG in charge needs to look at implementations to make its decision. > Kevin Kane and I are scheduled to investigate this for IoTivity in the > coming months, and we'll have a recommendation to discuss with this group. > In the meantime, if you have any thoughts or experience on the topic, > please share. Thanks Greg! -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center
