From joachim at assured.se Tue Jan 8 12:11:48 2019 From: joachim at assured.se (=?UTF-8?Q?Joachim_Str=c3=b6mbergson?=) Date: Tue, 8 Jan 2019 13:11:48 +0100 Subject: [Cryptech Tech] Getting sync_fmc branch to work In-Reply-To: <19106f2a-d04c-2d95-42d0-720d44421149@assured.se> References: <19106f2a-d04c-2d95-42d0-720d44421149@assured.se> Message-ID: <659d3fec-beec-5dc1-0f56-f3278d734466@assured.se> Aloha! Pavel: Did you perform the suggested test? Any result? Regards JoachimS On 2018-12-20 13:48, Joachim Str?mbergson wrote: > Aloha! > > First: Great work. That was one blizzard of commits. > > On 2018-12-20 12:57, Pavel Shatov wrote: >> Now the bad news. For some reason the new bitstream (`fpga show cores' >> should report ECDSA version 0.20 instead of 0.11 now) fails >> unit-tests.py. It locks up in hal_get_random() waiting for the valid bit >> of CSPRNG core to go high. If I disable this test, it locks up a bit >> further in 'test_attribute_bloat_token_big' which calls hal_uuid_gen() >> which in its turn again calls hal_get_random(). If I drop FMC clock to >> 60 MHz (line 156 of stm-fmc.c sets the divisor: 2 is for 90 MHz, 3 is >> for 60 MHz), then all the tests pass just fine. This is strange because >> we've already seen this situation, but then we clearly had failed >> timing, while now everything should be fine. I haven't done any thorough >> investigation yet, my very preliminary guess is that maybe we need to >> change the number of taps in the ring oscillator entropy source or >> something like that. I do have a platform cable, so given hints on where >> to look I can try to debug, but I suggest that someone first tries to >> reproduce the situation, because maybe I'm doing something wrong (not >> pulled latest changes from Joachim, etc...) > > Strange. > > Could you try and rerun the unit-tests a while later (as in minutes) > without resetting the FPGA. Basically run unit-tests, see that it hangs > and abort. Wait a while and run unit-tests later. > > If it is the ROSC core not delivering values, and that the RNG hasn't > yet initalized the CSPRNG and isn't ready to deliver random values it > should get to that point eventually. There are timeouts for the mixer to > wait for entropy from the entropy providers. As long as the external > avalanche source is alive, the mixer will end up with enough entropy > words. It will just take a number of timeouts for each word that it > should get from the ROSC core. > > > _______________________________________________ > Tech mailing list > Tech at cryptech.is > https://lists.cryptech.is/listinfo/tech > -- Med v?nlig h?lsning, Yours Joachim Str?mbergson ======================================================================== Assured AB ======================================================================== -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From meisterpaul1 at yandex.ru Tue Jan 8 14:00:09 2019 From: meisterpaul1 at yandex.ru (=?UTF-8?B?0J/QsNCy0LXQuyDQqNCw0YLQvtCy?=) Date: Tue, 8 Jan 2019 17:00:09 +0300 Subject: [Cryptech Tech] Getting sync_fmc branch to work In-Reply-To: <659d3fec-beec-5dc1-0f56-f3278d734466@assured.se> References: <19106f2a-d04c-2d95-42d0-720d44421149@assured.se> <659d3fec-beec-5dc1-0f56-f3278d734466@assured.se> Message-ID: 08.01.2019 15:11, Joachim Str?mbergson ?????: > Aloha! > Hi, > Pavel: Did you perform the suggested test? Any result? yes, unfortunately waiting (for up to an hour or so) didn't help. One thing I've discovered is that if I run all the unit-tests with 60 MHz and then switch FMC clock to 90 MHz without resetting the FPGA, the first unit test (hal_get_random) passes, but further tests that need random numbers lock up. I don't know the internals of the TRNG, it looks like at 90 MHz entropy pool is not replenished or something like that. > > Regards > JoachimS > > > On 2018-12-20 13:48, Joachim Str?mbergson wrote: >> Aloha! >> >> First: Great work. That was one blizzard of commits. >> >> On 2018-12-20 12:57, Pavel Shatov wrote: >>> Now the bad news. For some reason the new bitstream (`fpga show cores' >>> should report ECDSA version 0.20 instead of 0.11 now) fails >>> unit-tests.py. It locks up in hal_get_random() waiting for the valid bit >>> of CSPRNG core to go high. If I disable this test, it locks up a bit >>> further in 'test_attribute_bloat_token_big' which calls hal_uuid_gen() >>> which in its turn again calls hal_get_random(). If I drop FMC clock to >>> 60 MHz (line 156 of stm-fmc.c sets the divisor: 2 is for 90 MHz, 3 is >>> for 60 MHz), then all the tests pass just fine. This is strange because >>> we've already seen this situation, but then we clearly had failed >>> timing, while now everything should be fine. I haven't done any thorough >>> investigation yet, my very preliminary guess is that maybe we need to >>> change the number of taps in the ring oscillator entropy source or >>> something like that. I do have a platform cable, so given hints on where >>> to look I can try to debug, but I suggest that someone first tries to >>> reproduce the situation, because maybe I'm doing something wrong (not >>> pulled latest changes from Joachim, etc...) >> >> Strange. >> >> Could you try and rerun the unit-tests a while later (as in minutes) >> without resetting the FPGA. Basically run unit-tests, see that it hangs >> and abort. Wait a while and run unit-tests later. >> >> If it is the ROSC core not delivering values, and that the RNG hasn't >> yet initalized the CSPRNG and isn't ready to deliver random values it >> should get to that point eventually. There are timeouts for the mixer to >> wait for entropy from the entropy providers. As long as the external >> avalanche source is alive, the mixer will end up with enough entropy >> words. It will just take a number of timeouts for each word that it >> should get from the ROSC core. >> >> >> _______________________________________________ >> Tech mailing list >> Tech at cryptech.is >> https://lists.cryptech.is/listinfo/tech >> > > -- ? ?????????, ????? ????? From joachim.strombergson at assured.se Wed Jan 23 19:16:22 2019 From: joachim.strombergson at assured.se (=?utf-8?Q?Joachim_Str=C3=B6mbergson?=) Date: Wed, 23 Jan 2019 20:16:22 +0100 Subject: [Cryptech Tech] The compcert compiler Message-ID: Aloha! This appeared on HN yesterday. A formally verified compiler. It can generate code for ARM. Something we could use perhaps? http://compcert.inria.fr/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From joachim at assured.se Thu Jan 24 14:54:17 2019 From: joachim at assured.se (=?UTF-8?Q?Joachim_Str=c3=b6mbergson?=) Date: Thu, 24 Jan 2019 15:54:17 +0100 Subject: [Cryptech Tech] Zymkey Message-ID: <0d54a3ab-b939-50cc-3aab-82952499238d@assured.se> Aloha! I bumped into a neat little security device called Zymkey: https://www.zymbit.com/zymkey/ The Zymkey is a small, i2c connected board with battery backup that provide active tamper detect, root of trust, key storage etc for RPi and other IoT devices. Zymkey seems to provide a lot of the things we have been discussing for the Alpha. Unfortunately it seems that the Zymkey is not open source so reviewing the SW seems not to be possible. Or compiling the FW yourself for that matter. -- Med v?nlig h?lsning, Yours Joachim Str?mbergson ======================================================================== Assured AB ======================================================================== -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From sra at hactrn.net Thu Jan 24 15:23:52 2019 From: sra at hactrn.net (Rob Austein) Date: Thu, 24 Jan 2019 10:23:52 -0500 Subject: [Cryptech Tech] The compcert compiler In-Reply-To: References: Message-ID: <20190124152352.C4C84200BB3B80@minas-ithil.hactrn.net> On Wed, 23 Jan 2019 14:16:22 -0500, Joachim Str?mbergson wrote: > > This appeared on HN yesterday. A formally verified compiler. It can > generate code for ARM. Something we could use perhaps? > > http://compcert.inria.fr/ I would not object if someone were to contribute code showing how to use that compiler as an alternative to gcc, but it's not free software (download page says "no commercial use"), so switching to it entirely seems problematic. Unclear how close it is to being a drop-in replacement for gcc. Command line syntax as shown in the manual is very gcc-like, but stm32 builds use enough fiddly gcc options that there are likely to be divergences, the questions would be how serious and how hard to fix. From pgut001 at cs.auckland.ac.nz Thu Jan 24 15:40:14 2019 From: pgut001 at cs.auckland.ac.nz (Peter Gutmann) Date: Thu, 24 Jan 2019 15:40:14 +0000 Subject: [Cryptech Tech] The compcert compiler In-Reply-To: <20190124152352.C4C84200BB3B80@minas-ithil.hactrn.net> References: , <20190124152352.C4C84200BB3B80@minas-ithil.hactrn.net> Message-ID: <1548344380472.45254@cs.auckland.ac.nz> Rob Austein writes: >Unclear how close it is to being a drop-in replacement for gcc. Command line >syntax as shown in the manual is very gcc-like, but stm32 builds use enough >fiddly gcc options that there are likely to be divergences, the questions >would be how serious and how hard to fix. >Unclear how close it is to being a drop-in replacement for gcc. Command line >syntax as shown in the manual is very gcc-like, but stm32 builds use enough >fiddly gcc options that there are likely to be divergences, the questions >would be how serious and how hard to fix. I looked at it a while back and it's kinda painful to work with, you need a bunch of other oddball tools, and specific versions of some of the tools, and those tools need further tools, and eventually you end up going down a rabbit hole of dependencies to the point where I gave up before getting anything working. From what I've read about it it's a decent-enough compiler, but if you just want to play with it for a bit to see what it's like it's a bit too much effort. (It seems to be a built-in misfeature of a lot of code and binary analysis tools that they were developed to work with one very specific config and don't work with anything else. Not a criticism of compcert, but of all the code/binary-analysis tools that are written up in reports and conference papers: - The vast majority are never published. - Of the ones that are published, many will never work outside the specific environment that the authors have set up. - Of the ones that are published and can be made to work on a generic system, way too much work is typically required to get them running. And when they are set up, updates to any of them components they use can break them. So sticking with clang or gcc is a pretty safe option, you can move to the latest version and (a) it'll just work and (b) it probably won't break things). Peter.