feat(core): add libtropic to unix build

[ibz]

• This PR adds libtropic as a dependency to the Unix build and exposes its functionality to micropython.
• Build currently fails in the CI pipeline because libtropic is a private repository. We should wait for it to be open sourced before we can merge this PR.
• This setup requires the Tropic model to be running and accepting connections over TCP. The Tropic model emulates the actual chip.
• A smoke test is provided as part of the core/ unit tests.
• The model itself is also not open sourced yet so it has to be installed locally for testing locally and it will have to be installed as part of the CI pipeline for the tests to work.
• The emulator launcher (emu.py) has a way to run the Tropic model automatically - this is for convenience, when testing manually using the emulator. The added benefit is not much, since one could just run it separately, but this place seemed like a good point to provide some basic documentation about how to set up the model, and to enforce a path where everybody will have it set up, for consistency.

Requirements for merging this PR:

• libtropic is open sourced (mandatory)
• the model is open sourced - we can actually drop this requirement if we decide to not run the smoke tests as part of the CI pipeline

TODO before merging:

• start model as part of the Python unit tests runner (core/tests/run_tests.sh)

[prusnak]

Suggested change

	"vendor/libtropic/hal//port/unix/lt_port_unix.c",
	"vendor/libtropic/hal/port/unix/lt_port_unix.c",

[prusnak]

Maybe this should be USE_TS_CRYPTO, no?

Suggested change

	defines += ["USE_TREZOR_CRYPTO"]
	defines += ["USE_TS_CRYPTO"]

[ibz]

Maybe this should be USE_TS_CRYPTO, no?

Actually, I was thinking not, because this is the emulator build, in which we would still use TREZOR_CRYPTO, because the TS chip is not there. What do you think, @pavelpolach321?

[pavelpolach321]

In libtropic we use USE_TREZOR_CRYPTO define if we want to use trezor_crypto as a source of cryptographic code which is running on host (MCU) side.

Example: https://github.com/tropicsquare/libtropic/blob/master/hal/crypto/trezor_crypto/ts_trezor_x25519.c#L1

Therefore I think that passing USE_TREZOR_CRYPTO to compilation of libtropic files will work in your case?

[prusnak]

Why convert to hex here? IMHO just return raw binary bytes and if we need hex we can call foo.hex() in Python.

Suggested change

	vstr_t vstr = {0};
	vstr_init_len(&vstr, 1024);
	bytes_to_chars(X509_cert, vstr.buf, 512);
	return mp_obj_new_str_from_vstr(&mp_type_bytes, &vstr);
	return mp_obj_new_str_copy(&mp_type_str, X509_cert, 512);

[pavelpolach321]

Maybe you should put 'ret =' in front of this function call?

[pavelpolach321]

I would also check return value in all lt_deinit() calls, mainly because in emulator this function internally talks to tcp server, which could fail easily.

[onvej-sl]

Hello @ibz, I wanted to ask if you could use fixup commits instead of force-pushing. Fixup commits make it easier to track which suggestions have already been addressed. We usually squash the fixup commits just before merging the pull request.

[onvej-sl]

As one of the developers involved in integrating Optiga into Trezor, I would like to document the architecture we used for the integration. The following diagrams shows the dependencies of all relevant functions where Optiga is utilized:

graph TD
    subgraph optiga_transport["core∕embed∕trezorhal∕optiga∕optiga_transport.c"]
    optiga_sec_chan_handshake
    optiga_init
    optiga_execute_command
    end
    subgraph optiga_commands["core∕embed∕trezorhal∕optiga∕optiga_commands.c"]
    optiga_calc_sign --> optiga_execute_command     
    optiga_get_data_object --> optiga_execute_command    
    optiga_set_autostate --> optiga_execute_command  

    optiga_get_random --> optiga_execute_command             
    end    
    subgraph optiga["core∕embed∕trezorhal∕optiga∕optiga.c"]
    optiga_sign --> optiga_calc_sign
    optiga_read_cert --> optiga_get_data_object
    optiga_random_buffer --> optiga_get_random
    optiga_pin_verify --> optiga_set_autostate    
    end
    subgraph storage["storage∕storage.c"]
    storage_unlock --> optiga_pin_verify
    end
    subgraph modoptiga["core∕embed∕extmod∕modtrezorcrypto∕modtrezorcrypto_optiga.h"]
    sign --> optiga_sign
    get_cert --> optiga_read_cert
    end
    subgraph modconfig["core∕embed∕extmod∕modtrezorconfig∕modtrezorconfig.c"]
    unlock --> storage_unlock
    end
    subgraph modrandom["core∕embed∕extmod∕modtrezorcrypto∕modtrezorcrypto_random.c"]
    random_bytes --> optiga_random_buffer
    end    
    subgraph modmain["core∕embed∕kernel∕main.c"]
    driver_init --> optiga_sec_chan_handshake
    driver_init --> optiga_init
    end

Loading

Note that the functions optiga_sec_chan_handshake and optiga_init (which are perhaps analogous to tropic_init) are defined outside python modules (core/embed/extmod/**). The reason for this is that we call them from core/embed/kernel/main.c. However, I'm not certain if this is sufficient justification, since it seems to me that they could be called only after the micropython environment is initialized.

I am not claiming that the architecture is perfect nor that there are no reasons to integrate Tropic differently. However, it would be nice, if we could keep it consistent.

One significant difference is that we don't have an Optiga emulator. How will the code in this pull request differ if we use a physical device instead of an emulator?

[onvej-sl]

Why don't you call tropic_init once, keep the handle, and reuse it for multiple commands? It seems unnecessary to me to call it before every command.

[onvej-sl]

I'm not sure if we need this method. If we want to generate randomness in python, we would like to combine entropy from Tropic, Optiga and MCU, so we rather need to integrate Tropic into this function.

[ibz]

Hello @ibz, I wanted to ask if you could use fixup commits instead of force-pushing. Fixup commits make it easier to track which suggestions have already been addressed. We usually squash the fixup commits just before merging the pull request.

Got it, sorry for that! BTW, I just force-pushed again, because I rebased on main. There's no way around that, I suppose... But I will do fixup commits from now on.

[ibz]

Note that the functions optiga_sec_chan_handshake and optiga_init (which are perhaps analogous to tropic_init) are defined outside python modules (core/embed/extmod/**). The reason for this is that we call them from core/embed/kernel/main.c. However, I'm not certain if this is sufficient justification, since it seems to me that they could be called only after the micropython environment is initialized.

Indeed, I can move tropic_init out of the Python module. We should probably call it in the same place where we call optiga_init, which is in main.c.

I am not claiming that the architecture is perfect nor that there are no reasons to integrate Tropic differently. However, it would be nice, if we could keep it consistent.

By this did you mean just the above part, about tropic_init? Or the other difference - that optiga comes under trezorhal whereas tropic does not?

The way I see it ... we have the optiga HAL (for the real chip) and the "unix" optiga HAL (for the emulator) - which are two different things. But in the case of tropic, libtropic is what provides the abstraction - because it can talk either to the real chip, or to the model, over TCP. So there would be no HAL layer (or - rather - libtropic is the HAL). This is why I went to just expose libtropic to Python without adding anything under trezorhal. But I can do it otherwise, if you think that is a good idea.

[onvej-sl]

Indeed, I can move tropic_init out of the Python module. We should probably call it in the same place where we call optiga_init, which is in main.c.

One reason for initializing optiga in main.c was that the handshake process uses a secret stored in a memory location that becomes inaccessible once the firmware enters unprivileged mode. It seems to me that this concept applies to tropic as well. It would be beneficial to store the production handshake keys in this area.

But in the case of tropic, libtropic is what provides the abstraction - because it can talk either to the real chip, or to the model, over TCP.

This is something I don't quite understand. Does it mean that libtropic itself manages the communication with the chip? How can I instruct libtropic to use a real chip instead of an emulator? How can I specify which interface (for example I2C bus index) it should use for communication with tropic.

[pavelpolach321]

Indeed, I can move tropic_init out of the Python module. We should probably call it in the same place where we call optiga_init, which is in main.c.

One reason for initializing optiga in main.c was that the handshake process uses a secret stored in a memory location that becomes inaccessible once the firmware enters unprivileged mode. It seems to me that this concept applies to tropic as well. It would be beneficial to store the production handshake keys in this area.

But in the case of tropic, libtropic is what provides the abstraction - because it can talk either to the real chip, or to the model, over TCP.

This is something I don't quite understand. Does it mean that libtropic itself manages the communication with the chip? How can I instruct libtropic to use a real chip instead of an emulator? How can I specify which interface (for example I2C bus index) it should use for communication with tropic.

Hello, libtropic manages the communication by using its platform specific c file during compilation. For compiling for embedded target, use this file in your makefile: https://github.com/tropicsquare/libtropic/blob/develop/hal/port/stm32/lt_port_stm32.c - have a look from line 241 to the end.
For compiling for unix environment (your emulator), where you expect libtropic to talk to TROPIC01 model over tcp, then use this file
https://github.com/tropicsquare/libtropic/blob/develop/hal/port/unix/lt_port_unix.c

edit: you could also define transport layer's primitives for your embedded environment. For example within your codebase create lt_port_trezor.c and fill it with definitions for interfaces described by this header file: https://github.com/tropicsquare/libtropic/blob/develop/include/libtropic_port.h