K82 : mbedTLS and ECC P-521

[EugeneHiihtaja]

Hello !

I can see in latest SDK for K82, in mbedTLS 2.6.0 support for ECC P-521 curve cryptography is disabled.

E.g MBEDTLS_ECP_DP_SECP521R1_ENABLED   definition is disabled.

I think this is becouse LTC supports 512 bit modulo as maximum.

But even I enable this flag and disable LTC usage by undefine

//#define MBEDTLS_ECP_MUL_COMB_ALT
//#define MBEDTLS_ECP_ADD_ALT

I still not able to pass any tests for P-521.

Does K82 port of mbedTLS include ECC P-521 software implementation ?

Regards,

Eugene

[EugeneHiihtaja]

Hi Mark !

Thank you !

Regards,

Eugene

[mjbcswitzerland]

Hi Eugene

Although NXP puts the mbedTLS middleware code in their libraries I don't expect that there will necessarily be any specialist knowledge (apart from maybe ensuring that the hooks to the mmCAU and LTC are there and working).
It is probably best to use the armMBED forums (with Crypto and SSL questions) at https://forums.mbed.com/ for mbedTLS discussions since that is where the mbedTLS guru Ron Eldor hangs out (and will be able to explain all such details within a short time). Here it is otherwise more like the blind leading the blind.... ;-)
Personaly I have analysed and know details about various usage cases and ciphers but never needed ECC P-521, and thus have no explicit knowledge of its requirements.

And, yes, some things are VERY slow and require lots of memory........(making security in small, low-power, cheap IoT a real challenge).

Regards

Mark

[bobpaddock]

"making security in small, low-power, cheap IoT a real challenge"

Yes.  The people screaming the loudest  about IoT security don't think at the power per bit energy consumption levels. :-(

A few people are starting to get the idea.  Alas still not working at the lowest levels of hardware and firmware as we must.

NIST Issues Call for "Lightweight Cryptography" Algorithms - Schneier on Security 

NIST Cybersecurity for IoT Program

NIST Cybersecurity for IoT Program | NIST 

Draft Interagency Report, NISTIR 8200, Summarizes International Efforts to Standardize Internet of Things Cybersecurity 

Draft Interagency Report, NISTIR 8200, Summarizes International | CSRC 

"Platform Firmware Resiliency Guidelines"
https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-193.pdf 

[mjbcswitzerland]

Hi Bob

Agreed - there are some real conflicts.

IoT is supported to allow billions of cheap sensors to communicate across the globe (i.e. small, cheap, low-power) but security is of paramount importance, which dictates 100MHz+ processors with 128k+ RAM (and with the recent price increases for processors $10+) and adequate energy to feed it to do the job in order to allow anything to be done at more than a snail's pace.
Possibly it will end up with a subset of "just enough" security standardised for "not that critical" IoT devices implemented in HW to allow a reasonable cost/speed to be achieved.

Then someone will discover the next security loop hole and all will need to be replaced.....

It would be so much easier if we humans could all become decent people and just not try to steal other people's data in the first place...;-)

Regards

Mark

See also Securely Plug & Trust your IoT devices with NXP's A71CH Secure Element|NXP 
and the A71CH A71CH | Plug and Trust for IoT|NXP 

[EugeneHiihtaja]

Hi Mark !

I think SW implementation works in mbedTLS 2.6.0 works but all memory footprint  parameters should be set to the maximum.

BEDTLS_ECP_WINDOW_SIZE - 6
MBEDTLS_ECP_FIXED_POINT_OPTIM - 1
MBEDTLS_MPI_MAX_SIZE - 1024
MBEDTLS_MPI_WINDOW_SIZE - 6
MBEDTLS_SSL_MAX_CONTENT_LEN - 10240

But it is really too slow.

Regards,

Eugene

[EugeneHiihtaja]

Hi Mark !

After some trials I have got impression that SW implementation for P-521 in mbedTLS dosn't work yet.

SelfTest is not pass, benchmark generate BufFault in MPU enabled enviroment or freeze somewhere in generic SDK test.

So if it is should work in 2.6.0 I will start to investigate in more details.

Regards,

Eugene

[EugeneHiihtaja]

Hi Mark !

 If i enable this flag, some operations are routed to LTC, but it cause BusFault. By checking dependencies and reading RM I have got impression

that LTC is not able to accelerate P-521 due natural HW limitations.

I'm not able to make SW implementation to work yet. P-384 , by using SW,  work fine but it 10x slowly than HW one.

So even it will work, it might be so slow than it dosn't have sense to any real application.

But I need confirmation for my investigations for be sure if it really so.

By the way, is any schedule available for new K82 SDK where mbedTLS 2.7.5 and freeRTOS 10.1.0 will be taken in ?

Regards,

Eugene

[mjbcswitzerland]

Eugene

This is what WolfSSL has LTC support for:

If it doesn't list the support that you need it is very probably that it is not possible in HW with the controller.

Regards

Mark

[mjbcswitzerland]

Eugene

MBEDTLS_ECP_DP_SECP521R1_ENABLED is disabled in the standard mbedTLS 2.6.0 package so it has nothing to do with the K82.

The software implementation is purely in the mbedTLS code and again is not K82 specific.

If you think that it is HW related, run the code in a different environment (I use mbedTLS in the uTasker project and with Visual Studio - on a virtual K82, which allows checking for HW dependencies in case of doubt as well as better monitoring the internal operations). Beware that mbedTLS is also very heap-oriented and you need to be careful that no calloc() failures are occurring since it is not always obvious. You also need to check carefully return codes since they may point to a reason why something is not behaving. Beware also that tests with peers may need the peer to be correctly configured to support the modes of operation that are to be used (i.e. failures may not always at one side of tests).

Regards

Mark

http://www.utasker.com/kinetis/FRDM-K82F.html