Hi,
So as the topic stated I want to be sure that:
All this concerning the usage of Teensy 3.6 (it can also be 3.2 or 3.5) connected to linux machine which runs user application.
My thoughts:
1.
Firstly I wanted to use the MAC address. For example I get the address from controller compare it with data stored in user app side and then unlock the device. But in my case - I am buying the mian chip and bootloader chip separately so the MAC is useless (factory set to FF:FF:...:FF). Then I wanted to use the Serial number however after some conversation with Paul, the serial number also seems to be useless.
Another question is the uniqueness of the serial number assinged by bootloader - I made new thread for that - https://forum.pjrc.com/threads/5688...number-to-brand-new-chips?p=209717#post209717
2.
And finally if something goes wrong (different hardware, check for license failed etc.) the device should not start - application that control the device should show error etc.
I image that during the in company setting-up process the hardware and software should be somehow securely and permanently paired with user application once. So as I wrote I am thinking about combining the hardware id's with some product specific description provided in firmware. I am waiting for your opinions and suggestions.
~Matthew
So as the topic stated I want to be sure that:
- the device which I am selling will be used untouched as I provided it - same hardware with same software which authenticate the product itself, and
- store some persistence licence info about the customer and product number - make device uniquely traceable.
All this concerning the usage of Teensy 3.6 (it can also be 3.2 or 3.5) connected to linux machine which runs user application.
My thoughts:
1.
Firstly I wanted to use the MAC address. For example I get the address from controller compare it with data stored in user app side and then unlock the device. But in my case - I am buying the mian chip and bootloader chip separately so the MAC is useless (factory set to FF:FF:...:FF). Then I wanted to use the Serial number however after some conversation with Paul, the serial number also seems to be useless.
However however, the serial number alone probably isn't a useful way to check for authenticity, since it's easy to craft a USB device which simply sends the same descriptors
Another question is the uniqueness of the serial number assinged by bootloader - I made new thread for that - https://forum.pjrc.com/threads/5688...number-to-brand-new-chips?p=209717#post209717
2.
- I will use the option of blocking access to flash memory (FSEC set to secured), so I can flash program with already provided customer data and product number and AFAIK I can feel safe as secure as the NXP system is - tell me if I am wrong. I can make special app for this purpose to automate the build process with customer data provided from app and store that in some company internal database as well. So it not inconvenient for me.
- However 2a will generate new .hex file - not good in my case. I would like rather keep one .hex and provide the customer data externally from special app using my custom protocol over USB in "factory safe conditions". For example if I flash the program for the first time, I can enter the data once and after this process the access is blocked by setting some data in EEPROM. Which one is better in security terms? Or maybe there is a better solution? I'am aiming also at automation of the process but it is not the issue due to small forecasted annual sale.
And finally if something goes wrong (different hardware, check for license failed etc.) the device should not start - application that control the device should show error etc.
I image that during the in company setting-up process the hardware and software should be somehow securely and permanently paired with user application once. So as I wrote I am thinking about combining the hardware id's with some product specific description provided in firmware. I am waiting for your opinions and suggestions.
~Matthew