Le 22/05/2020 à 17:00, Takashi Yamamoto a écrit :
On Fri, May 22, 2020 at 7:26 PM Sebastien Lorquet <sebast...@lorquet.fr> wrote:
Hello
Le 22/05/2020 à 10:05, Takashi Yamamoto a écrit :
can you explain what's "real nuttx code"?
For me, code specifically written for NuttX with good integration and
performance. Different from a third-party library.
i'm afraid that a third-party library is likely a better choice for
things like tls.
Probably not, my company is already working in the domain of security
and we will have some testing to ensure things work.
Yes I know it's bad to roll your own crypto but it's not rolling crypto,
it's rolling known algorithms, so these can be tested and fixed.
To finish with, the security envelope of a normal IoT SoC is pretty bad
so already. If you get physical access you can put break points at the
right places and do whatever you want.
So the goal is more compactness and integration.
We will not be as comprehensive as mbedtls probably, but we will do it
well for sure. The customer that ordered it is a large french company
that does not sh*t on security. Domain is industrial, not
iot/startup/customer.
Moreover mbedtls comes with a full crypto lib which will be duplicated
if something else in the system requires cryptography, and these lib
wont take advantage of any crypto hardware that might be available in a
particular SoC.
Using a backend crypto library improves modularity.
The makefile glue is OK for NuttX contribution.
Crypto is a directory that exists in some personal forks of NuttX and is
(IIRC) used by Xiaomi with probably many changes, but it is not
integrated yet. (your remark made me believe it had been already)
It is intended to provide a PKCS#11 like library that any app can use
and any board can extend with new algs, including hardware implemented.
If you are interested in a crypto API we can talk about that and discuss
what is already done and designed, no need to fully reinvent anything.
i'm interested.
It's here: https://bitbucket.org/slorquet/nuttx/src/crypto/crypto/
Still a legacy nuttx, not migrated to apache stuff yet.
You can see the suggested API here. it's based on IOCTL and chardevs
https://bitbucket.org/slorquet/nuttx/src/crypto/include/nuttx/crypto/ioctl.h
constant definitions
https://bitbucket.org/slorquet/nuttx/src/crypto/include/nuttx/crypto/manager.h
"OS side" crypto module operations (kind of service provider API)
https://bitbucket.org/slorquet/nuttx/src/crypto/include/nuttx/crypto/module.h
chardev interface
https://bitbucket.org/slorquet/nuttx/src/crypto/crypto/manager.c
Implementation of module manager
https://bitbucket.org/slorquet/nuttx/src/crypto/crypto/libmanager.c
Module designed to test the behaviour
https://bitbucket.org/slorquet/nuttx/src/crypto/crypto/softmodule.c
cryptoapps is a repo that can be cloned in a working APPS repository.
new folder is automatically detected by the build system, this is what
you can do for mbedtls porting.
https://bitbucket.org/slorquet/cryptoapps/src/master/
user-side of the API that calls the chardev:
https://bitbucket.org/slorquet/cryptoapps/src/master/libcrypto/
openssl-like test tool used during development
https://bitbucket.org/slorquet/cryptoapps/src/master/ct/
export should be linked as crypto in apps/include to provide headers to
other apps.
It is extensively documented with comments.
The great question was : how to make this API available to user space?
My initial development was based on a character device because it was
very simple and had probably the less impact on performance.
I know that gregory would prefer something else, possibly a kind of
socket like netlink. I think it's bloat to require the network stack for
simple straightforward stuff like this, and situation was left on this
lack of solution the last time I remember.
I dont know how things are now. is the char device still unacceptable?
is netlink the preferred solution? Is something else possible? I dont know.
Sebastien
