feat(core): add libtropic to unix build #4172

ibz · 2024-09-11T14:15:04Z

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 · 2024-09-15T17:04:17Z

core/site_scons/models/T3T1/emulator.py

+            "vendor/libtropic/src/lt_l2_frame_check.c",
+            "vendor/libtropic/src/lt_l3.c",
+            "vendor/libtropic/src/lt_random.c",
+            "vendor/libtropic/hal//port/unix/lt_port_unix.c",


Suggested change

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

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

prusnak · 2024-09-15T17:09:54Z

core/site_scons/models/T3T1/emulator.py

+            "vendor/libtropic/hal/crypto/trezor_crypto/lt_crypto_trezor_sha256.c",
+            "vendor/libtropic/hal/crypto/trezor_crypto/lt_crypto_trezor_x25519.c",
+        ]
+        defines += ["USE_TREZOR_CRYPTO"]


Maybe this should be USE_TS_CRYPTO, no?

Suggested change

defines += ["USE_TREZOR_CRYPTO"]

defines += ["USE_TS_CRYPTO"]

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?

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 · 2024-09-15T17:14:06Z

core/embed/extmod/modtrezorcrypto/modtrezorcrypto-tropic.h

+    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);


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 · 2024-09-24T06:48:45Z

core/embed/extmod/modtrezorcrypto/modtrezorcrypto-tropic.h

+
+  tropic_init(&handle);
+
+  lt_ecc_key_generate(&handle, idx, CURVE_ED25519);


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

pavelpolach321 · 2024-09-24T06:54:57Z

core/embed/extmod/modtrezorcrypto/modtrezorcrypto-tropic.h

+    return mp_const_none;
+  }
+
+  lt_deinit(&handle);


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 · 2024-10-09T17:53:23Z

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 · 2024-10-09T17:57:42Z

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

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 · 2024-10-09T18:05:06Z

core/embed/extmod/modtrezorcrypto/modtrezorcrypto-tropic.h

+  lt_handle_t handle = {0};
+  lt_ret_t ret = LT_FAIL;
+
+  tropic_init(&handle);


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.

Something like this? 0c33e89#diff-e1a3e03160d11080fcca39f3a8a9205fde724d8cd7d61c8505f6f41c9a95b04fR46

onvej-sl · 2024-10-09T18:10:07Z

core/embed/extmod/modtrezorcrypto/modtrezorcrypto-tropic.h

+/// def random_get(
+///     len: int,
+/// ) -> bytes:
+///     """
+///     Get number of random bytes.
+///     """
+STATIC mp_obj_t mod_trezorcrypto_tropic_random_get(mp_obj_t len) {
+  mp_int_t len_rand = mp_obj_get_int(len);
+  if (len_rand < 0 || len_rand > RANDOM_VALUE_GET_LEN_MAX) {
+    mp_raise_ValueError("Invalid length.");
+  }
+
+  lt_handle_t handle = {0};
+  lt_ret_t ret = LT_FAIL;
+
+  tropic_init(&handle);
+
+  uint8_t buff[RANDOM_VALUE_GET_LEN_MAX] = {0};
+  ret = lt_random_get(&handle, buff, len_rand);
+  if (ret != LT_OK) {
+    tropic_deinit(&handle);
+    mp_raise_msg(&mp_type_TropicError, "lt_random_get failed.");
+  }
+
+  tropic_deinit(&handle);
+
+  vstr_t vstr = {0};
+  vstr_init_len(&vstr, len_rand);
+
+  memcpy(vstr.buf, buff, len_rand);
+
+  return mp_obj_new_str_from_vstr(&mp_type_bytes, &vstr);
+}
+STATIC MP_DEFINE_CONST_FUN_OBJ_1(mod_trezorcrypto_tropic_random_get_obj,
+                                 mod_trezorcrypto_tropic_random_get);
+


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.

Removed it 0c33e89#diff-e1a3e03160d11080fcca39f3a8a9205fde724d8cd7d61c8505f6f41c9a95b04fL183

ibz · 2024-11-04T12:13:39Z

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 · 2024-11-04T14:35:30Z

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 · 2024-11-05T13:34:43Z

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 · 2024-11-05T14:01:28Z

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

onvej-sl · 2024-11-18T14:35:08Z

Thank you for the explanation. It makes sense to me now. This line is what causes the build to use an emulator instead of a physical device.

I still don't understand whether we have to perform a handshake before every command. See this comment. Trezor with optiga performs a handshake once during startup and then reuses the handle. Is there any benefit in performing the handshake for each individual command?

ibz · 2024-11-18T15:03:38Z

I still don't understand whether we have to perform a handshake before every command. See this comment. Trezor with optiga performs a handshake once during startup and then reuses the handle. Is there any benefit in performing the handshake for each individual command?

We don't. That is my mistake. Will fix.

onvej-sl · 2024-11-19T14:54:56Z

My suggestion is to:

Store SHiPRIV_BYTES in core/embed/sec/secret/unix/secret.c.
Introduce a function, secret_tropic_get_privkey, in core/embed/sec/secret/unix/secret.c. This function will return SHiPRIV_BYTES. This can be built on top of this pull request.
Introduce a function, tropic_handshake(const uint8_t *trezor_privkey), in core/embed/sec/tropic/tropic_transport.c. This function will compute the public key using curve25519_scalarmult_basepoint, call lt_handshake, and store the handle.
In core/embed/projects/kernel/main.c, call tropic_handshake and lt_init.

Once we want to use a physical tropic, we will implement core/embed/sec/secret/model_with_tropic/secret.c, and use port_model_with_tropic.c instead of lt_port_unix.c.

The tropic commands can then be called either directly using libtropic and the handle in tropic_transport.c, or through wrappers that will be in tropic_commands.c.

I am still uncertain about the variable naming. Does this approach make sense to you?

github-actions · 2024-11-27T14:50:51Z

legacy UI changes	device test(screens) main(screens)

github-actions · 2024-11-27T14:50:55Z

core UI changes	device test	click test	persistence test
T2T1 Model T	test(screens) main(screens)	test(screens) main(screens)	test(screens) main(screens)
T3B1 Safe 3	test(screens) main(screens)	test(screens) main(screens)	test(screens) main(screens)
T3T1 Safe 5	test(screens) main(screens)	test(screens) main(screens)	test(screens) main(screens)
All	main(screens)

ibz self-assigned this Sep 11, 2024

prusnak requested changes Sep 15, 2024

View reviewed changes

ibz force-pushed the ibz/20240805-libtropic branch 3 times, most recently from f41ec36 to e91f6cb Compare September 16, 2024 15:07

ibz force-pushed the ibz/20240805-libtropic branch 3 times, most recently from c9485c3 to 47d4427 Compare September 23, 2024 14:45

pavelpolach321 reviewed Sep 24, 2024

View reviewed changes

ibz force-pushed the ibz/20240805-libtropic branch 2 times, most recently from 4b65b70 to 94517e4 Compare September 25, 2024 16:47

ibz marked this pull request as ready for review September 26, 2024 09:58

ibz requested a review from matejcik as a code owner September 26, 2024 09:58

ibz requested a review from andrewkozlik September 26, 2024 09:58

ibz force-pushed the ibz/20240805-libtropic branch from 94517e4 to 3c77bf0 Compare October 2, 2024 09:00

onvej-sl reviewed Oct 9, 2024

View reviewed changes

ibz force-pushed the ibz/20240805-libtropic branch from 3c77bf0 to 7283ff6 Compare November 4, 2024 12:11

onvej-sl mentioned this pull request Nov 20, 2024

Use separate implementation of secret.c for unix #4363

Merged

feat(core): add libtropic to unix build

d316d88

ibz added 5 commits November 27, 2024 15:49

chore(core/tests): add smoke test for libtropic

45891cb

chore(core): add ability for emu launcher to launch tropic model

ce62dc6

fixup! feat(core): add libtropic to unix build

ff3f1de

fixup! chore(core/tests): add smoke test for libtropic

9567cca

chore(core/tropic): update libtropic.

21d26d6

ibz force-pushed the ibz/20240805-libtropic branch from 832300b to 21d26d6 Compare November 27, 2024 14:50

ibz added 2 commits November 27, 2024 16:18

fixup! feat(core): add libtropic to unix build

14a5770

fixup! fixup! feat(core): add libtropic to unix build

3bf8f12

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

feat(core): add libtropic to unix build #4172

feat(core): add libtropic to unix build #4172

ibz commented Sep 11, 2024 •

edited

Loading

prusnak Sep 15, 2024

prusnak Sep 15, 2024

ibz Sep 16, 2024

pavelpolach321 Sep 17, 2024

prusnak Sep 15, 2024 •

edited

Loading

pavelpolach321 Sep 24, 2024

pavelpolach321 Sep 24, 2024 •

edited

Loading

onvej-sl commented Oct 9, 2024

onvej-sl commented Oct 9, 2024

onvej-sl Oct 9, 2024

ibz Nov 22, 2024 •

edited

Loading

onvej-sl Oct 9, 2024 •

edited

Loading

ibz Nov 22, 2024

ibz commented Nov 4, 2024

ibz commented Nov 4, 2024

onvej-sl commented Nov 5, 2024

pavelpolach321 commented Nov 5, 2024 •

edited

Loading

onvej-sl commented Nov 18, 2024

ibz commented Nov 18, 2024

onvej-sl commented Nov 19, 2024 •

edited

Loading

github-actions bot commented Nov 27, 2024 •

edited

Loading

github-actions bot commented Nov 27, 2024 •

edited

Loading

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

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


		tropic_init(&handle);

		lt_ecc_key_generate(&handle, idx, CURVE_ED25519);

feat(core): add libtropic to unix build #4172

Are you sure you want to change the base?

feat(core): add libtropic to unix build #4172

Conversation

ibz commented Sep 11, 2024 • edited Loading

prusnak Sep 15, 2024

Choose a reason for hiding this comment

prusnak Sep 15, 2024

Choose a reason for hiding this comment

ibz Sep 16, 2024

Choose a reason for hiding this comment

pavelpolach321 Sep 17, 2024

Choose a reason for hiding this comment

prusnak Sep 15, 2024 • edited Loading

Choose a reason for hiding this comment

pavelpolach321 Sep 24, 2024

Choose a reason for hiding this comment

pavelpolach321 Sep 24, 2024 • edited Loading

Choose a reason for hiding this comment

onvej-sl commented Oct 9, 2024

onvej-sl commented Oct 9, 2024

onvej-sl Oct 9, 2024

Choose a reason for hiding this comment

ibz Nov 22, 2024 • edited Loading

Choose a reason for hiding this comment

onvej-sl Oct 9, 2024 • edited Loading

Choose a reason for hiding this comment

ibz Nov 22, 2024

Choose a reason for hiding this comment

ibz commented Nov 4, 2024

ibz commented Nov 4, 2024

onvej-sl commented Nov 5, 2024

pavelpolach321 commented Nov 5, 2024 • edited Loading

onvej-sl commented Nov 18, 2024

ibz commented Nov 18, 2024

onvej-sl commented Nov 19, 2024 • edited Loading

github-actions bot commented Nov 27, 2024 • edited Loading

github-actions bot commented Nov 27, 2024 • edited Loading

ibz commented Sep 11, 2024 •

edited

Loading

prusnak Sep 15, 2024 •

edited

Loading

pavelpolach321 Sep 24, 2024 •

edited

Loading

ibz Nov 22, 2024 •

edited

Loading

onvej-sl Oct 9, 2024 •

edited

Loading

pavelpolach321 commented Nov 5, 2024 •

edited

Loading

onvej-sl commented Nov 19, 2024 •

edited

Loading

github-actions bot commented Nov 27, 2024 •

edited

Loading

github-actions bot commented Nov 27, 2024 •

edited

Loading