Connector for stacking crypto and mezzanine on top of hikey 960 or dragonboard 410c

Products Support HiKey 960
#1

I would like to use both a) mezzanine board and b) secure96 boards with Hikey 960. I assume I need some kind of stack header, otherwise many grove connectors are hidden by the secure96 board. I saw one proposed on https://github.com/96boards/96boards-sensors/commit/73021ebd3f4c55f3c6352203df1d511f63c52b79, but it’s not possible to trace where this can be bought from, and maybe it’s not for this purpose also?

Your help is appreciated. Also, please advise which library you propose to use for secure96? There are several ones that we have tried and do not work, but I assume there is one that works?

Miltos

#2

What do you mean by “a) mezzanine board”?

mezzanine board is a generic term (the secure96 is a mezzanine board) but the rest of your post talks makes it sound like you have a specific board in mind.

#3

I think this question really boils down to just getting some more space between the boards to fit some connectors.

Secure96 uses only the LS connector, so it could theoretically be stacked onto any board that exposes a 2mm 2x20 F header.

And you could use something really simple like this to add a bit of space;
https://www.mouser.ca/ProductDetail/Molex/79107-7019?qs=sGAEpiMZZMs%2BGHln7q6pm3mOARR4%2FbOm2fmVw9zLCac%3D

Or this (note: despite the inaccurate picture, this one is a right-angle mount, which would rotate the secure96 90 degrees up from the lower board): https://www.mouser.ca/ProductDetail/Samtec/SQT-120-01-L-D-RA?qs=sGAEpiMZZMs%2BGHln7q6pm82iqn1YqlrLFkG38oN1429mhM1CNCFDcA%3D%3D

#4

It might do… but, depending on what mezzanine board is being sandwiched, I was concerned that there might also be electrical issues to worry about (for example, the UART bridge on secure96 might need to be desoldered).

#5

Would it actually fail if you had 2 stacked UART bridges?
I think the worst consequence of stacked UART bridges is that the UART might not work [entirely]. Probably just wouldn’t be able to send in the USB → UART direction. I would expect it to still work in the other direction.

#6

I couldn’t really say whether or not there would be physical damage, silicon is both surprisingly resilient and surprisingly fragile!

Secure96 doesn’t have any current limiting resistors on LS-UART0-RX so, whilst I would not expect damage, I’d be inclined to be careful with the choice of middle board.

#7

It looks interesting to prototype a secure IoT solution, using one of 96boards (e.g. Hikey, Dragonboard 410c etc), a mezzanine sensor board, and secure96 (or even tresor) board.

Right now we have a partial solution without security. We can receive sensor data from grove sensors on Linux side either directly or via serial connection to Arduino on mezzanine board (which is doing periodic writes to uart device). Reading from Linux side is done via python (mraa library).

Thus, I would like to ask, if secure96 or tresor board can be supported in this setup (together with mezzanine sensor board) to achieve hw authentication of the hybrid system (including 96 board & mezzanine sensor board).

It may also be helpful, besides the hardware issues discussed, to identify any working library/ies that we can use for secure96 (e.g. ATSHA204, but also ATECC508A, or TPM crypto chips). But maybe it’s better to summarize our findings on a secure96 thread?

Thanks.

Miltos

#8

Why do you need libraries? These devices are supported by drivers in the kernel.

And could you be a bit more detailed in what you are trying to achieve? I.e., what is the relationship between the sensors and secure96 mezzanine boards? What is the purpose in using the secure96? Are you certain that it is actually necessary in order to achieve that purpose?

#9
  1. This would be good news. Do you mean there exists a generic i2c kernel driver (for sending packet commands), or an integrated cryptoauthlib+i2c kernel driver for secure96? The latter would be really more helpful. (I am running a late image, e.g. for Hikey 960.)
  2. For secure96 question. We like to authenticate & encrypt device data obtained from sensors prior to sending to a server, who would then use a similar chip, e.g. secure96 or ATSHA204a to verify hashes, decrypt and process. This is a hardware crypto solution, probably safer and at the same time faster (near to real-time) than a software solution. But that is a research question.

Thanks

#10

These are the drivers for the 3 crypto chips on the board;
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/drivers/crypto/atmel-sha204a.c?h=v5.4.22
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/drivers/crypto/atmel-ecc.c?h=v5.4.22
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/drivers/char/tpm/tpm_tis_spi.c?h=v5.4.22

However, I still wonder about the benefits of going with the secure96 mezzanine over just handling this on the CPU. What is the potential security hole(s) that you are trying to plug? Are you concerned that the SBC’s OS will become compromised, exposing your credentials? Are you trying to protect the data from 3rd party access? Are you trying to ensure the data validity where a 3rd party might attempt to inject invalid data? I would remind you that despite being plugged together, there is no direct path for sensor data to be sent from the sensors mezzanine to the secure96 mezzanine. It has to be received by the CPU first and then from there sent through the TPM and back.

Regarding performance and theoretical hardware security benefits; on the Hikey960 (but not the dragonboard 410c), you have access to aarch64 crypto extensions, tee/optee, etc. Even for the db410c, I very much doubt that you could pull enough sensor data through i2c/gpio to bother the CPU much with encryption.

#11

Thanks so much for the links (we are trying now to build the new kernel on hikey 960). It seems support so far is limited to RNG only for ATSHA204A, however it’s a big step in the right direction that really helps.

You have lots of valid questions. Two points:
a) Performance; Assuming that the threats are outside of a smart box (which consists of Hikey 960, mezzanine sensors and secure96), we examine how to authenticate sensor data efficiently, i.e. we are concerned with performance (since security relates to QoS and real-time). Related to this, I think it is faster to call hardware crypto function outside CPU rather than use CPU software?

b) Security. Your statement “I would remind you that despite being plugged together, there is no direct path for sensor data to be sent from the sensors mezzanine to the secure96 mezzanine” puzzles me. Isn’t it possible to integrate ATSHA204a or ATECC608 (maybe ATAES128 too) crypto chips (but not secure96) directly to Arduino on mezzanine sensor board maybe via some of the existing I2C connectors (or soldering) on the same board? Then, really assuming Arduino can do all the crypto itself, the CPU must only propagate to the server only ciphertext data (authenticated/encrypted data)? Perhaps even key exchange works so that the CPU is completely transparent and (Arduino, Server) form together a pair of trust?

#12

Looking at the schematic for the 96boards-sensors board I think a direct path from the AVR to the crypto chips may be possible. All the I2C crypto chips are on LS-I2C0 and the LS-I2C0 pins do go through a level converter to the AVR. In other words I think the AVR could master the bus (although no promises… the level converters for I2C are tricky things). Given how fragile multi-master I2C is I think it would also mean the hikey960 I2C would have to be disabled leaving only LS-UART1 as the only way to get the data from the AVR to the base board (so you would definitely need to desolder the FTDI chip from the secure96).