Jetson TK1 ECDSA verify failure??

Autonomous Machines Jetson & Embedded Systems Jetson TK1
1

Hi All,

I recently purchased the TK1 Dev Kit, and I have been testing various benchmarks to see if we can use this hardware in a product.

I ran “openssl speed” to get some basic benchmark data before trying to setup/run parallel activities.

However, I ran into a problem when it came to sing/verify ecdsa’s. I kept seeing “ECDSA verify failure”. I’ve never seen that before when running this benchmark. I’ve copied the relevant benchmark output below.

Has anyone else seen this issue using the Jetson TK1 DevKit? Could it be inherent to the customized Ubuntu, or maybe I’m just doing something wrong?

Doing 160 bit sign ecdsa's for 10s: 53825 160 bit ECDSA signs in 9.97s
Doing 160 bit verify ecdsa's for 10s: 14772 160 bit ECDSA verify in 9.99s
Doing 192 bit sign ecdsa's for 10s: 43248 192 bit ECDSA signs in 9.98s
Doing 192 bit verify ecdsa's for 10s: 11186 192 bit ECDSA verify in 10.00s
Doing 224 bit sign ecdsa's for 10s: 34104 224 bit ECDSA signs in 9.99s
Doing 224 bit verify ecdsa's for 10s: 8361 224 bit ECDSA verify in 10.00s
Doing 256 bit sign ecdsa's for 10s: 27963 256 bit ECDSA signs in 9.98s
Doing 256 bit verify ecdsa's for 10s: 6556 256 bit ECDSA verify in 10.00s
Doing 384 bit sign ecdsa's for 10s: 12796 384 bit ECDSA signs in 9.99s
Doing 384 bit verify ecdsa's for 10s: 2659 384 bit ECDSA verify in 10.00s
Doing 521 bit sign ecdsa's for 10s: 5687 521 bit ECDSA signs in 10.00s
Doing 521 bit verify ecdsa's for 10s: 1052 521 bit ECDSA verify in 10.00s
Doing 163 bit sign ecdsa's for 10s: 15744 163 bit ECDSA signs in 9.99s
Doing 163 bit verify ecdsa's for 10s: 5335 163 bit ECDSA verify in 10.00s
Doing 233 bit sign ecdsa's for 10s: 7573 233 bit ECDSA signs in 9.99s
Doing 233 bit verify ecdsa's for 10s: ECDSA verify failure
1 233 bit ECDSA verify in 10.00s
Doing 283 bit sign ecdsa's for 10s: 5031 283 bit ECDSA signs in 10.00s
Doing 283 bit verify ecdsa's for 10s: 1580 283 bit ECDSA verify in 10.00s
Doing 409 bit sign ecdsa's for 10s: 1778 409 bit ECDSA signs in 10.00s
ECDSA verify failure.  No ECDSA verify will be done.
Doing 571 bit sign ecdsa's for 10s: 799 571 bit ECDSA signs in 10.01s
Doing 571 bit verify ecdsa's for 10s: 321 571 bit ECDSA verify in 10.01s
Doing 163 bit sign ecdsa's for 10s: 15819 163 bit ECDSA signs in 9.99s
Doing 163 bit verify ecdsa's for 10s: ECDSA verify failure
1 163 bit ECDSA verify in 10.00s
Doing 233 bit sign ecdsa's for 10s: 7624 233 bit ECDSA signs in 9.99s
Doing 233 bit verify ecdsa's for 10s: 2674 233 bit ECDSA verify in 10.00s
Doing 283 bit sign ecdsa's for 10s: 5033 283 bit ECDSA signs in 10.00s
Doing 283 bit verify ecdsa's for 10s: ECDSA verify failure
1 283 bit ECDSA verify in 10.00s
Doing 409 bit sign ecdsa's for 10s: 1775 409 bit ECDSA signs in 10.00s
Doing 409 bit verify ecdsa's for 10s: 661 409 bit ECDSA verify in 10.01s
Doing 571 bit sign ecdsa's for 10s: 800 571 bit ECDSA signs in 10.00s
Doing 571 bit verify ecdsa's for 10s: 278 571 bit ECDSA verify in 10.02s

Here’s the Summary:

sign    verify    sign/s verify/s
 160 bit ecdsa (secp160r1)   0.0002s   0.0007s   5398.7   1478.7
 192 bit ecdsa (nistp192)   0.0002s   0.0009s   4333.5   1118.6
 224 bit ecdsa (nistp224)   0.0003s   0.0012s   3413.8    836.1
 256 bit ecdsa (nistp256)   0.0004s   0.0015s   2801.9    655.6
 384 bit ecdsa (nistp384)   0.0008s   0.0038s   1280.9    265.9
 521 bit ecdsa (nistp521)   0.0018s   0.0095s    568.7    105.2
 163 bit ecdsa (nistk163)   0.0006s   0.0019s   1576.0    533.5
 233 bit ecdsa (nistk233)   0.0013s  10.0000s    758.1      0.1
 283 bit ecdsa (nistk283)   0.0020s   0.0063s    503.1    158.0
 571 bit ecdsa (nistk571)   0.0125s   0.0312s     79.8     32.1
 163 bit ecdsa (nistb163)   0.0006s  10.0000s   1583.5      0.1
 233 bit ecdsa (nistb233)   0.0013s   0.0037s    763.2    267.4
 283 bit ecdsa (nistb283)   0.0020s  10.0000s    503.3      0.1
 409 bit ecdsa (nistb409)   0.0056s   0.0151s    177.5     66.0
 571 bit ecdsa (nistb571)   0.0125s   0.0360s     80.0     27.7
2

I have R19.3 installed, the default is R19.2. I also have updated packages from right after flash of 19.3. So my version probably differs slightly…but what command line did you use? I might be able to reproduce it, but only with the same command.

The function used to verify is ECDSA_verify(), which has different return values. The issue is that the failure message only differentiates between success and not success, but the ECDSA_verify() itself differentates between two possible causes of failure: (1), actual bad signature, and (2) other reasons. If I could reproduce this, I could probably figure out an actual reason. I could see the possibility of something simple like a timer function not having time…this would not be a big thing, whereas an actual verify failure would be bad.

3

Thanks for the help looking into this.
The command I ran was:

openssl speed

It benchmarks a variety of SSL/TLS elements.

4

I can confirm the error. My R19.3 has OpenSSL version 1.0.1f, possibly the same as on R19.2. I have done apt-get upgrade, whether or not OpenSSL was updated I do not know. The most recent version from openssl.org is 1.0.1h; however, this newer version will not compile on L4T R19.3, as other supporting libraries would need updates which are not available without manually compiling all of them. Initial indications are that this is not a hardware issue, but in fact an OpenSSL issue.

The failure itself is on the elliptic curve DSA (ECDSA) during speed testing, as reported from ECDSA_verify(). The file reporting this failure is “apps/speed.c”, with the verify function defined in “crypto/ecdsa/ecs_vrf.c”. The verify function can return two types of failure, one being an actual bad signature, or just “other”. The speed test does not differentiate between “other” and signature failure, so I changed the code to explicity state failure type, and ran the speed test again (re-compile was on native Jetson-tk1). There may be a flaw in my testing, in that I did not make install; I created /usr/local/ssl/, and inside this placed a symbolic link pointing to /etc/ssl/openssl.cnf; I ran openssl directly out of the apps directory of the source compile tree.

The result is that actual ECDSA signature has failed. What makes this interesting is that it only fails on a small percent of the tests. This would infer that the algorithms used are likely correct, but some more uncommon test patterns fail for non-algorithm reasons (e.g., architecture-dependent bit shifting incorrectly for a small sample of data due to architecture differences).

The documentation that arrives with OpenSSL itself notes the ability to compile a “make report”, which showed no error (self-test passed). Another documentation suggestion is to build with no assembler (./config no-asm). The result was PASSING (no more ECDSA failures).

I’m just speculating, but I suspect that this failure will on rare occasions result in ECDSA falsely claiming a bad signature. If you need this to always work, the immediate workaround would be to manually download and install version 1.0.1f from openssl.org and to configure/compile with no-asm. The best case (which I believe would be painful) is to upgrade every package which recent version 1.0.1h depends on, and hope the upgraded version solved the issue (but it might not…the no-asm change could be required there too).

5

Thanks for your help!
After reading your post I went through some of the openssl documents as well.
I noticed the FAQ says that using no-asm would “sacrifice a great deal of performance”.
Is that something you noticed when you compiled openssl with ./config no-asm?

6

I did not use the no-asm, but this is high on the list of where a programming error could cause this. I suspect that somewhere in the bit shifting something is different between the way it was done in general versus the way it was done for ARMv7…and that is often in asm, rather than C. I’m not sure if I still have that installed, I might poke around and if it is still there try the no-asm flag.