101 Reply by dgarske

(1 replies, posted in wolfTPM)

Hi tpm2user,

I am not familiar with `openssl.ctx` or ` --key-context`, however I can show you have to load an external private key to the null hierarchy.

1) make sure you are using DER format (binary ASN.1, not PEM). Use `-outform der`.
2) Use `wc_RsaPrivateKeyDecode`
3) `wolfTPM2_RsaKey_WolfToTpm_ex` to load into a WOLFTPM2_KEY.

We have an example here:
https://github.com/wolfSSL/wolfTPM/blob … est.c#L431

However I don't have one loading a PEM or DER to the null hierarchy. I'll see about adding an example for this.

Thanks,
David Garske, wolfSSL

Go to forum: wolfTPM

102 Reply by dgarske

(5 replies, posted in wolfTPM)

Hi tpm2user,

1) Load the TPM public key into a wolfCrypt ecc_key struct: https://github.com/wolfSSL/wolfTPM/blob … ent.c#L226
2) Extract public key as DER: wc_EccPublicKeyToDer: https://github.com/wolfSSL/wolfTPM/blob … ent.c#L363
3) Use DER with wolfSSL_CTX_use_PrivateKey_buffer and WOLFSSL_FILETYPE_ASN1

Thanks,
David Garske, wolfSSL

Go to forum: wolfTPM

103 Reply by dgarske

(5 replies, posted in wolfTPM)

Hi tpm2user,

1) For wolfSSL when using a TPM private key for TLS you need to extract the public key and pass it to the `wolfSSL_CTX_use_PrivateKey_*` function. The TLS examples were all updated recently to do this. See PR https://github.com/wolfSSL/wolfTPM/pull/210
The use_PrivateKey functions support variations to allow using a file or buffer as PEM or DER.

2) The crypto callback requires registering a callback function (like wolfTPM2_CryptoDevCb) with a devId value. Then you use `wolfSSL_CTX_SetDevId` to tell the TLS layer and all internal keys to use the crypto callback.

Thanks,
David Garske, wolfSSL

Go to forum: wolfTPM

104 Reply by dgarske

(4 replies, posted in wolfSSL)

Hi SRSR333,

FYI: The fix has also been published here:
https://github.com/wolfSSL/wolfssl/pull/5328

Thanks,
David Garske, wolfSSL

Go to forum: wolfSSL

105 Reply by dgarske

(6 replies, posted in wolfTPM)

Hi celov65111,

An X.509 certificate only contains a public key.

To compare the public key of the certificate to the TPM:
1) Read the public key from the TPM using something like `wolfTPM2_ReadPublicKey`
2) 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`.
3) Extract the public key from the X.509 certificate.

#include "wolfssl/wolfcrypt/settings.h"
#include "wolfssl/wolfcrypt/asn.h"

int ret;
DecodedCert cert;

InitDecodedCert(&cert, certBuffer, certLen, NULL);
ret = ParseCert(&cert, CERT_TYPE, NO_VERIFY, NULL);
if (ret == 0) {
    printf("Public Key %d\n", cert.pubKeySize);
    WOLFSSL_BUFFER(cert.publicKey, cert.pubKeySize);
    
}
FreeDecodedCert(&cert);

Also make sure you verify the signature of the certificate. You can pass `VERIFY` instead of `NO_VERIFY` on ParseCert. The 4th argument lets you pass in a Certificate Manager pointer for validating the signature against a trusted certificate. We have an example for that here: https://github.com/wolfSSL/wolfssl-exam … fybuffer.c

Thanks,
David Garske, wolfSSL

Go to forum: wolfTPM

106 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

107 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

108 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

109 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

110 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

111 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

112 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

113 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

114 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

115 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

116 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

117 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

118 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

119 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

120 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

121 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

122 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

123 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

124 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

125 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