NHS3100: How to make the tlogger secure?

[stevewald]

We are using the NHS3100. We know there are products better suited, but for now we are stuck with this part. We want to extend the tlogger firmware and App functionality to make the logging more secure over the mission of the tag.

1. We would like to at least ensure that a) the firmware is protected from prying eyes, b) that we can configure the tag's mission in a way that the configuration cannot be altered until complete, and c) that we can authenticate the integrity of the data log at mission completion at least to some reasonable degree.
2. The 3100 has no hardware support for encryption, but we have developed software encryption which could be used. We need to know more about the interaction between the tags and the readers in a crypto-secure environment to keep the temperature log unaltered by unauthorized means.
3. The document FTF-MHW-N1980 mentions AES and passwords in connection with access control for NHS3100 on slide 63, but gives few details. How might this be done?
4. There are Lock and Protect bits in the flash, but we cannot find out how to exercise them. There is nothing in the SDK, and no hint of functions to work with them. Is there a document to explain the access and mapping of these bits?

Thanks,

Steve

[driesmoors]

Hi Steve,

1. We would like to at least ensure that
   a) the firmware is protected from prying eyes,
   The IC has 3 levels of Code Read Protection (CRP). Check <SDK>/docs/firmware/ > SW Debug Considerations
   
   b) that we can configure the tag's mission in a way that the configuration cannot be altered until complete, and
   The firmware can block this, since a tag reader has no direct access to the FLASH and the ARM EEPROM. It must the firmware to do the copying to the NFC memory. 
   
   c) that we can authenticate the integrity of the data log at mission completion at least to some reasonable degree.
   The data log can be appended with a hash, derived from the 16-byte unique ID of each IC. This unique ID is not directly accessible by a tag reader.
   
   
2. The 3100 has no hardware support for encryption, but we have developed software encryption which could be used. We need to know more about the interaction between the tags and the readers in a crypto-secure environment to keep the temperature log unaltered by unauthorized means.
   A good question, and not an easy one. This is best tackled in a more private conversation. AFAIK a lot depends on your specific use case.
   
   
3. The document FTF-MHW-N1980 mentions AES and passwords in connection with access control for NHS3100 on slide 63, but gives few details. How might this be done?
   Simple password control relies on a cleartext exchange of a shared secret. In the SDK this can be used to dynamically block or allow the high-level msg commands sent from tag reader to tag. I suggest using the MSG_COMMAND_ACCEPT_CB diversity setting in the msg module to do this.
   AES also involves a share secret, but can be used for zero-knowledge communication to prove the identity of each side. This will consequences for your communication flow, and more severe adaptations to the SDK demo applications will be necessary. Best seems to find a standardized communication scheme and implement this on top of the command/response exchanges currently demonstrated in the demos.
   
4. There are Lock and Protect bits in the flash, but we cannot find out how to exercise them. There is nothing in the SDK, and no hint of functions to work with them. Is there a document to explain the access and mapping of these bits?
   The SDK does not provide support for this, unfortunately. I also don't have a document that explains how to do this.

Thanks,

Steve