search

tillitis / tillitis-key1

Board designs, FPGA verilog, firmware for TKey, the flexible and open USB security key 🔑
https://www.tillitis.se
391 stars 24 forks source link

I/O problems #24

Closed quite closed 1 year ago

quite commented 1 year ago

I furnished a script to run signing in a loop. After some 1000-2000 iterations, the signing hangs. This on 38400 bps.

I seemed to have hung on getSig in the signerapp. So a byte was lost, and the ReadFull() hung because it never got the whole frame, the whole size that it expected? Possibly

When trying this at 500_000 bps, it would hang after some 10s of signing iterations.

quite commented 1 year ago

One small observation: when signing has hung, device is back flashing blue. So i should be able to sign again, right? i try, but it doesn't work -- the first getPubkey cmd doesn't have the expected number of bytes in the response.

I also tried -- upon connecting to the device -- to first read any "left over" bytes, and then proceed to sign (like, was there something laying around there?). didn't work in the same way.

So, is there then something wonky with the state of the device's fifo...

secworks commented 1 year ago

There is no TX FIFO, so unless FW itself has a buffer that it is trying to send there wouldn't be any data left to send. Since device is flashing blue I assume that it is not ready to send stuff, but to receive stuff (commands). But you do get a response when asking for a pubkey? And are the number of missing bytes the same?

There could be something wonky with the RX FIFO. But we need to isolate when hanging occurs. Is it always at the same situation? One thing we could try is look at if the FIFO get full. We currently have no detection of this, but could be added.

quite commented 1 year ago

Yesterday I set up uart.v for 40000 bps, which is a nice and even divisor of 450. I started the test-loop and it ran overnight successfully (I stopped it now after more than 16h). 105000 iterations! So we might have both the fractional divisor issue (with 38400), and some other speeding issue?

quite commented 1 year ago

Ran 62500 overnight -- a supposedly good bps for both fpga-uart and ch552. After 47000 iterations (almost 7 hours) the signing loop had stopped, because a signature from the device could not be verified.

The next "good" number is 100_000 bps, but that hangs very soon.

secworks commented 1 year ago

I think we have concluded that 62500 is what works. It is the default bitrate since several weeks. I suggest that we close this issue.