76 Reply by dgarske

(6 replies, posted in wolfTPM)

Hi celov65111,

A certificate contains a public key which is signed by another key who is trusted. To verify a certificate you only need the public key for the signer. Typically the AKID (Authority Key Identifier) is used to identify the signer key. It is a hash of the signers public key.

If a TPM private key was used to sign you only need to have the public key to verify a certificate, since a verify is a pubic only operation.

You can export a TPM RSA public key using `wolfTPM2_RsaKey_TpmToPemPub`. Or you could export a RSA public key DER/ASN.1 using `wolfTPM2_RsaKey_TpmToWolf` and `wc_RsaKeyToPublicDer_ex. For ECC public key you can use `wolfTPM2_EccKey_TpmToWolf` and `wc_EccPublicKeyToDer`.

For validating a certificate you could leverage our wolfSSL Certificate Manager to do a certificate validation. See example here:
https://github.com/wolfSSL/wolfssl-exam … fybuffer.c

If you are looking for a more direct approach you could just do:
1) Hash the certificate (minus trailing signature)
2) Use wc_ecc_verify_hash or wc_RsaSSL_VerifyInline with the public key and hash to verify signature.

For reference a KEYBLOB is key material from the TPM in a TPM format. The private key is encrypted and not usable except when loaded to the TPM. The public portion of a key blob is exportable and can be used for wolfCrypt operations using the above conversion API's.

If you have more questions if would be helpful to know more about your project. Feel free to email us directly support at wolfssl.com and reference this ticket.

Thanks,
David Garske, wolfSSL

Go to forum: wolfTPM

77 Reply by dgarske

(4 replies, posted in wolfSSL)

Hi labonte_d,

The Windows build uses the user_settings.h from IDE\VS-ARM. You must define WOLFSSL_USER_SETTINGS in your application "Realm" and make sure the same user_settings.h is in your include path. The changes directly to settings.h should not be made. Instead add them to your customized user_settings.h based on the one in IDE\VS-ARM. In your application code make sure wolfssl/wolfcrypt/settings.h is included before any other wolfssl or compatibility headers. The settings.h includes user_settings.h when WOLFSSL_USER_SETTINGS is defined.

Thanks,
David Garske, wolfSSL

Go to forum: wolfSSL

78 Reply by dgarske

(4 replies, posted in wolfSSL)

Hi labonte_d,

These errors indicate you did not include wolfssl/options.h before any of the wolfSSL headers. When you run ./configure --enable-opensslextra is generated a file containing the build options used in wolfssl/options.h. It is important your application also includes this before any other wolfSSL headers to enable the same build options in the header.

We do support the compatibility functions mentioned above. Make sure you setup the include path for the wolfssl-root and also wolfssl-root/wolfssl. Then make sure you have wolfssl/option.sh included and then openssl/sha.h, openssl/bio.h, etc...

Let me know if that does not help.

Thanks,
David Garske, wolfSSL

Go to forum: wolfSSL

79 Reply by dgarske

(5 replies, posted in wolfSSL)

Hi lili,

Make sure you have the wolfcrypt/src/kdf.c file included. Make sure you have `WOLFSSL_HAVE_PRF` defined.
Are you using the latest wolfSSL v5.3.0 Cube pack?

Thanks,
David Garske, wolfSSL

Go to forum: wolfSSL

80 Reply by dgarske

(5 replies, posted in wolfSSL)

Hi lili,

It is "-fomit-frame-pointer" added to the CFLAGS that you can use in debug mode to resolve this.

Thanks,
David Garske, wolfSSL

Go to forum: wolfSSL

81 Reply by dgarske

(5 replies, posted in wolfSSL)

Hi lili,

This happens only in debug mode. In release mode this goes away. This is due to the use of R7 I believe. There is a cflag that can be used to workaround this like -frame-omit-pointer, but I cannot find my note on that right now.

Another option is to use math option 3 in debug and math option 4 (asm) in release. The asm does increase math performance multiple x.

Thanks,
David Garske, wolfSSL

Go to forum: wolfSSL

82 Reply by dgarske

(4 replies, posted in wolfBoot)

Hi ballen,

To accomplish a split partition between onboard and external QSPI you will need to implement your own custom image_sha256() function to have awareness of the partition geometry, since the SHA calculation is currently done on contiguous addresses.

We support the NXP Kinetis K82 hardware and the K81 is compatible. The FRDM-K82F board we use for testing has an external QSPI with XIP support, which I have used successfully. However, I have not tried setting up a split boot partition. If you would like some consulting help with this feature please email facts@wolfssl.com with some project details and we can quote this. If you would like to implement support and provide these changes upstream feel free to open a GitHub pull request.

Thanks,
David Garske, wolfSSL

Go to forum: wolfBoot

83 Reply by dgarske

(2 replies, posted in wolfCrypt)

Hi Reid,

I've posted the fix here:
https://github.com/wolfSSL/wolfssl/pull/4844

Thanks,
David Garske, wolfSSL

Go to forum: wolfCrypt

84 Reply by dgarske

(2 replies, posted in wolfCrypt)

Hi Reid,

Thanks for the pointer to the benchmarking code argument issue. I'll post a fix for shortly.
The benchmarking isn't testing the data inputs/outputs, so the use of the buffer is not critical.

If you are looking for AES CBC test cases see wolfcrypt/test/test.c -> `aes_cbc_test`.

Are you seeing the AES benchmarks you expected? Depending on your platform you might consider using `--enable-intelasm` or `--enable-armasm` to speed up symmetric AES/SHA.

Let me know if you have any further questions.

Thanks,
David Garske, wolfSSL

Go to forum: wolfCrypt

85 Reply by dgarske

(1 replies, posted in wolfSSL)

Hi Mario,

Are you confident the python wolfSSL server is working correctly? You might try using our built-in C 

./examples/server/server -b -p 8090

. I tried to setup the wolfssl-py here and looks like it is a bit outdated.

For the client side the call to wolfSSL_connect will trigger the EthernetSend with a client_hello TLS packet and the server should respond with a server_hello. You might consider enabling the client side debugging by building with 

DEBUG_WOLFSSL

and calling 

wolfSSL_Debugging_ON();

to see what is happening. You might also consider adding some debug statements in your ethernet send / recv functions. I did compare the client to our IDE/ARDUINO/sketches/wolfssl_client/wolfssl_client.ino.

Thanks,
David Garske, wolfSSL
Happy New Year!

Go to forum: wolfSSL

86 Reply by dgarske

(2 replies, posted in wolfTPM)

Hi François,

This is a great question! Currently our TIS layer uses polling to detect data ready, however some TPM's do have an interrupt pin available. I have the ST33 TPM and will look into adding this feature. Aside from the physical GPIO it will also depend on how the ST33 enables the IRQ pin use.

Until then another option is to implement a delay in the polling period using the `XTPM_WAIT` macro, which you can define like this 

#define XTPM_WAIT() usleep(1000)

.

If you do end up making changes to wolfTPM for IRQ support and would like to contribute them back, you are welcome to open a PR and sign a contributor agreement.

Thanks,
David Garske, wolfSSL

Go to forum: wolfTPM

87 Reply by dgarske

(16 replies, posted in wolfTPM)

Hi Roman,

Did you try a lower SPI bus speed like 2 MHz? With longer wires the SPI bus impedance will be high and not function correctly.

Thanks,
David Garske, wolfSSL

Go to forum: wolfTPM

88 Reply by dgarske

(16 replies, posted in wolfTPM)

Hi r-type,

Were you able to get wolfTPM working with the Asus E15028 (Nuvoton NPCT750) on a Pi? Make sure you have the SPI wait state build option enabled `WOLFTPM_CHECK_WAIT_STATE` or use the `./configure --enable-nuvoton` option. Note: I pushed a wolfTPM v2.3 release this week, which does have some Nuvoton Fixups.

Thanks,
David Garske, wolfSSL

Go to forum: wolfTPM

89 Reply by dgarske

(3 replies, posted in wolfCrypt)

Hi swapnil,

To be clear the default sizes of the static memory buckets are not tuned for your use-case. So you will want to supply custom buckets appropriately sized to optimize use.

Example:
#define WOLFMEM_BUCKETS=64,256,384,432,512,1632,2976,3456,16128
#define WOLFMEM_DIST=16,8,6,4,6,3,2,1,1"

You might also try: #define ALT_ECC_SIZE or if use ECC only adjust your #define FP_MAX_BITS (256*2).

For debugging the sizes try using `WOLFSSL_DEBUG_MEMORY`.

Thanks,
David Garske, wolfSSL

Go to forum: wolfCrypt

90 Reply by dgarske

(3 replies, posted in wolfSSL)

Hi Mor71,

Thank you so much for this report! I was able to reproduce and locate the server side bug. I've put up a fix here:
https://github.com/wolfSSL/wolfssl/pull/4509

Let me know if you continue to see any issues.

Thanks,
David Garske, wolfSSL

Go to forum: wolfSSL

91 Reply by dgarske

(3 replies, posted in wolfSSL)

Hi Mor71,

Thank you for the report. I am trying to setup a use-case to reproduce. If you have any further tips you can share please do. If you'd like to keep the details private you can email support@wolfssl.com and reference this forum post.

I will share my results shortly.

Thanks,
David Garske, wolfSSL

Go to forum: wolfSSL

92 Reply by dgarske

(3 replies, posted in wolfSSL)

Hi Elliot,

To be clear, wolfSSL does not require an RTOS. In the generated configuration if no RTOS is selected it will define SINGLE_THREADED. It is only our TLS in-memory example since it starts multiple threads, although even that could be written non-blocking and used in bare-metal with shared memory.

Let us know if you have any questions. It would be great to hear more about your project so we can best support you.

Thanks,
David Garske, wolfSSL

Go to forum: wolfSSL

93 Reply by dgarske

(3 replies, posted in wolfSSL)

Hi Elliot,

Please see this link:
https://github.com/wolfSSL/wolfssl/tree … /STM32Cube

The built-in example in IDE/STM32Cube/wolfssl-examples.c allows running the wolfCrypt test/benchmark and also an in-memory TLS cipher suite test (requires RTOS, with lots of heap and stack).

The wolfSSL cube pack pulls in the wolfSSL/wolfCrypt files and generates a configuration file `wolfSSL.I-CUBE-wolfSSL_conf.h`. This is included automatically with wolfssl/wolfcrypt/settings.h.

If you wanted to pull in your own TLS example from https://github.com/wolfSSL/wolfssl-exam … master/tls just make sure it includes "wolfssl/wolfcrypt/settings.h" instead of wolfssl/options.h.

To use LWIP socket interface add the build option WOLFSSL_LWIP. Or setup your own IO callbacks using WOLFSSL_USER_IO and setting them with `wolfSSL_SetIORecv` or `wolfSSL_SetIOSend` like in the https://github.com/wolfSSL/wolfssl-exam … callback.c example.

If you need to customize the generated configuration the easiest option is to rename "wolfSSL.I-CUBE-wolfSSL_conf.h" to "user_settings.h" and add build option WOLFSSL_USER_SETTINGS to your CFLAGS pre-processor macros.

Thanks,
David Garske, wolfSSL

Go to forum: wolfSSL

94 Reply by dgarske

(16 replies, posted in wolfTPM)

Hi r-type,

That is a great little module ASUS has for their motherboard. The steps you listed for wolfTPM with direct /dev/spi access looks great. Make sure you have the right SPI chip select. The PI has two and they are "/dev/spidev0.0" and "/dev/spidev0.1". The modules Nuvoton provides for the Pi use CS0 (Pin 24).

Also the reset line is active low, so if pulled low it will hold in reset, so make sure it is high. Also you should make sure you have a pull-up on the Chip Select pin to make sure it is only active when the Pi drives it. I would leave the IRQ line alone and not tie to anything. Use 3.3v for VCC.

Thanks,
David Garske, wolfSSL

Go to forum: wolfTPM

95 Reply by dgarske

(2 replies, posted in wolfMQTT)

Hi Seyyed,

As I understand it the SIM800 is a UART based TCP modem? We've done customer projects using the SIM800, but I do not have an example available.

We have a template for what that would look like in wolfMQTT here: https://github.com/wolfSSL/wolfMQTT/blo … mqttuart.c

Let us know if you have any questions.

Thanks,
David Garske, wolfSSL

Go to forum: wolfMQTT

96 Reply by dgarske

(7 replies, posted in wolfSSL)

Hi raghu,

I also had that issue at first. Make sure you've pulled that branch and reconfigured your cmake. You might even need to delete wolfssl/options.h.

git fetch origin pull/4368/head:cmake_cflags
git checkout cmake_cflags
rm wolfssl/options.h
rm -rf build
mkdir build
cd build
cmake -DCMAKE_C_FLAGS="-DWOLFSSL_AESGCM_STREAM" ..
make

Let us know if that does not help.

Thanks,
David Garske, wolfSSL

Go to forum: wolfSSL

97 Reply by dgarske

(7 replies, posted in wolfSSL)

Hi Raghu,

This sounds like a build configuration issue. If building with ./configure it generates a wolfssl/options.h with settings. It looks like our CMakeLists.txt also does this. Assuming you have `HAVE_AESGCM` and `WOLFSSL_AESGCM_STREAM` in the generated options.h, the next item to check is the include at the top of wolfcrypt/test/test.c is including wolfssl/options.h, which it does if WOLFSSL_USER_SETTINGS is not defined.

I don't see your options.h attached, so I am unable to confirm.

Thanks,
David Garske, wolfSSL

Go to forum: wolfSSL

98 Reply by dgarske

(1 replies, posted in wolfCrypt)

Hi ACV,

You can instead call `wolfCrypt_Init` and `wolfCrypt_Cleanup`. For most use-cases you are not required to call these, but I recommend it to future proof yourself.

Thanks,
David Garske, wolfSSL

Go to forum: wolfCrypt

99 Reply by dgarske

(3 replies, posted in wolfCrypt)

Hi ACV,

Thanks for those details and I agree the RISC-V stuff there is very SiFive specific.

My best pointer is the user_settings_template.h file here: https://github.com/wolfSSL/wolfssl/blob … template.h
It explains each build option.

Let me know if you need details on any specific build options. Many of these are covered in the user manual chapter 2. https://www.wolfssl.com/docs/wolfssl-manual/ch2/

Thanks,
David Garske, wolfSSL

Go to forum: wolfCrypt

100 Reply by dgarske

(3 replies, posted in wolfCrypt)

Hi ACV,

Have you seen our RISC-V examples here? https://github.com/wolfSSL/wolfssl/tree … /IDE/RISCV

To build wolfCrypt only you can define `WOLFCRYPT_ONLY` and compile the source files in wolfcrypt/src/*.c that are applicable. If you are not cross-compiling with ./configure I would recommend defining CFLAG -DWOLFSSL_USER_SETTINGS and adding your own `user_settings.h` file. Your include path needs to be in the wolfssl root. Then in your application make sure you include wolfssl/wolfcrypt/settings.h prior to any other wolfSSL headers.

We have some user_settings.h examples here:
https://github.com/wolfSSL/wolfssl/tree … es/configs

This is also covered in the FAQ here:
https://www.wolfssl.com/docs/frequently … r_wolfSSL?

Let us know if you have any issues.

Thanks,
David Garske, wolfSSL

Go to forum: wolfCrypt