(changing subject to start a new thread, discussion has drifted away from build
flags)
I'm generally in favor of using the crypto implementations provided by the OS
where possible. There are a few things to consider.
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).
In AllJoyn we use platform crypto, but the TLS equivalent is implemented in
AllJoyn (since it is nonstandard it doesn't exist in any platforms).
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.
3. Does certificate parsing & manipulation happen in IoTivity or
OpenSSL/CNG/mbedtls. (do you consider certificate functions as part of crypto)
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)
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.
Greg
-----Original Message-----
From: Dave Thaler
Sent: Thursday, September 22, 2016 8:56 PM
To: Nash, George <george.nash at intel.com>; Macieira, Thiago <thiago.macieira
at intel.com>
Cc: Gregg Reynolds <dev at mobileink.com>; iotivity-dev at lists.iotivity.org;
Greg Zaverucha <gregz at microsoft.com>; Kevin Kane <kkane at microsoft.com>
Subject: RE: [dev] SECURE build flag setting as default configuration
Yes we want to use CNG on Windows. (As a point of comparison, AllJoyn already
does.)
We will need to coordinate between the Security project and the Platform
Support project on this.
But either way, I think all use of tinydtls should be deleted.
Dave
> -----Original Message-----
> From: Nash, George [mailto:george.nash at intel.com]
> Sent: Friday, September 23, 2016 4:32 AM
> To: Macieira, Thiago <thiago.macieira at intel.com>
> Cc: Dave Thaler <dthaler at microsoft.com>; Gregg Reynolds
> <dev at mobileink.com>; iotivity-dev at lists.iotivity.org
> Subject: RE: [dev] SECURE build flag setting as default configuration
>
> The windows equivalent is the Cryptography API: Next Generation (CNG)
> library.
>
> I would like to second using the native encryption supported by the OS.
>
> It's still good to have encryption support for when moving to a system
> that does not have native encryption support. This could be the case
> for things like Arduino. It's more common to lack the native
> encryption support when working on embedded devices and I think that
> is more likely to be limited to iotivity-constrained than iotivity.
>
> -----Original Message-----
> From: Macieira, Thiago
> Sent: Wednesday, September 21, 2016 6:49 PM
> To: Nash, George <george.nash at intel.com>
> Cc: Dave Thaler <dthaler at microsoft.com>; Gregg Reynolds
> <dev at mobileink.com>; iotivity-dev at lists.iotivity.org
> Subject: Re: [dev] SECURE build flag setting as default configuration
>
> On quarta-feira, 21 de setembro de 2016 15:02:15 PDT Nash, George wrote:
> > 20:02:51 *********************************** Error:
> > **************************************** 20:02:51 * Please
> download mbedtls
> > using the following command: * 20:02:51 * $
> > git clone https://github.com/ARMmbed/mbedtls.git
> > extlibs/mbedtls/mbedtls *
> > 20:02:51
> >
> **********************************************************
> ************
> > *****
> > ********
>
> As we're moving to TCP/TLS support, we should also investigate using
> native encryption libraries instead of shipping our own. That's
> OpenSSL for Linux, SecureTransport for Apple OSes, and Microsoft may
> have something for Windows (I'm not familiar, Qt ships OpenSSL on Windows).
>
> This would allow us to offload responsibility for keeping the
> encryption software to the OS vendor. It also has benefits because
> encryption routines may be subject to export regulations in some countries.
>
> The feature that required mBed TLS should be reverted and rewritten
> using the native SSL/TLS routines, per OS. The architecture for that
> change was not reviewed in the mailing list.
>
> --
> Thiago Macieira - thiago.macieira (AT) intel.com
> Software Architect - Intel Open Source Technology Center
