This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

am335x-evm-05.07 -> incorrect openssl hashes?

Hi,

This is using SDK "ti-sdk-am335x-evm-05.07.00.00"

Using a freshly loaded SD card using prebuilt images and freshly booted, here is what I see:

am335x-evm login: root
root@am335x-evm:~# md5sum /media/mmcblk0p1/uImage
346b4bc26c838dd710303431c447efdd /media/mmcblk0p1/uImage

root@am335x-evm:~# openssl dgst -md5 /media/mmcblk0p1/uImage
MD5(/media/mmcblk0p1/uImage)= f62048e3a7bc3a61a443f1823702183b

root@am335x-evm:~# rm /dev/crypto

root@am335x-evm:~# openssl dgst -md5 /media/mmcblk0p1/uImage
MD5(/media/mmcblk0p1/uImage)= 346b4bc26c838dd710303431c447efdd

The hardware assisted hash is the odd man out. The software only hashes match.

Is this what others are seeing?

As a workaround, I have used the instructions at http://processors.wiki.ti.com/index.php/Build_OpenSSL_for_Sitara to build openssl, but I have left off the DUSE_CRYPTODEV_DIGESTS c flag. Now, after scp'ing the file onto the board and a fresh boot I see

am335x-evm login: root
root@am335x-evm:~# md5sum /media/mmcblk0p1/uImage
346b4bc26c838dd710303431c447efdd /media/mmcblk0p1/uImage

root@am335x-evm:~# /usr/local/ssl/bin/openssl dgst -md5 /media/mmcblk0p1/uImage
WARNING: can't open config file: /usr/local/ssl/openssl.cnf
MD5(/media/mmcblk0p1/uImage)= 346b4bc26c838dd710303431c447efdd

Now the hashes match without deleting /dev/crypto. Of course the benchmarks for hashes per second went way down. But I get correct hashes and still have fast encryption. (Note that I didn't scp the openssl.cnf file over)

Jimmy

  • Hello,

    I have issues with openssl and the hardware crypto interface as well.  My system is based on EZSDK 6.00.00.00.  Try using openssl to open google's web site.  With /dev/crypto present, I get this:

    root@am335x-evm:~# openssl s_client -connect www.google.com:443
    CONNECTED(00000004)
    depth=2 C = US, O = GeoTrust Inc., CN = GeoTrust Global CA
    verify error:num=20:unable to get local issuer certificate
    verify return:0
    1074677472:error:04091068:rsa routines:INT_RSA_VERIFY:bad signature:rsa_sign.c:189:
    1074677472:error:1408D07B:SSL routines:SSL3_GET_KEY_EXCHANGE:bad signature:s3_clnt.c:1574:
    ---

    If I remove /dev/crypto (will force software calculation):

    root@am335x-evm:~# openssl s_client -connect www.google.com:443
    CONNECTED(00000003)
    depth=2 C = US, O = GeoTrust Inc., CN = GeoTrust Global CA
    verify error:num=20:unable to get local issuer certificate
    verify return:0
    ---

    As you can see, there's something wrong with the hash calculations with hardware accelerated crypto engine.  I have no errors using software crypto.

    Is there a fix guys?  Seems best to turn off the HW crypto engine if it doesn't work properly.

  • Hi David,

    Have you re-built the OpenSSL or are you using OpenSSL 1.0.0j that comes as part of the SDK 6.0. We recently came across an issue with the HW SHA driver included in SDK 6.0 and s_client wherein we notcied RSA_verify error on devices having greater than 512MB Memory due to an issue with the SHA driver but this is not observed on the EVM or Beagle Bone device with less than 512MB EVMs. Does your hardware platform have more than 512MB, is the HIGHMEM flag in the Linux kernel enabled.

    Can you please give this patch a try and let me know if you still see this issue.

    8863.0001-OMAP4-sham-Explicitly-map-pages-in-HIGHMEM-before-Co.patch

    Can you please provide a log of openssl s_client -connect www.google.com:443 -debug and if that doesn`t help, can you let us know if you still see the issue after you disable only the SHA hardware acceleration in the kernel.

    You can disable SHA drivers in the Kernel by doing a menuconfig and going in the cryptograhic API menu and at the end of the list enter the enable HWA menu and deselect the OMAP4 SHAM option.

    Regards,

    Rahul 

  • I first tried rebuilding openssl ( I can't remember which version...latest a month or two ago) but that didn't solve the issue, so I reverted back to EZSDK version.  My system has 512MB of RAM and HIGHMEM is disabled in the kernel.

    TI EZSDK image running on BeagleBone (White) has HW crypto running (/dev/crypto is present), and openssl fails.

    Latest Debian image on BeagleBone Black, I see the HW crypto driver is disabled, and as such openssl is working.  If you are not using TI's image, openssl is probably working there since the developer community has disabled HW crypto.

    Does your patch still apply if I do not have HIGHMEM enabled?