Hello and congratulations on a phenomenal 4.0 release. This new board is absolutely stunning.
Are there any new security features / lock bit changes on the 4.0 ?
I am toying around with the idea of using a Teensy in a commercial product and was wondering about the best methods of protecting my code from being read / snooped / modified by end users or competitors without my permission.
Cheers.
We're currently not supporting use the code security features on Teensy 4.0.
A future version may add this support (as was done on Teensy 3.2), but that it at least 4 months away.
Thank you! Congratulations again!
Greetings! We've shipped dozens of units of an industrial product containing the T3.6 as its brains. I'd be very keen to migrate to the 4.1 once I can make our code secure. Any updates on when this might become available?Originally Posted by PaulStoffregen
cheers
Doug
Hi Paul,
I came across your tiny boards when I searched development boards with ARM Cortex-M7 and when I saw that you are using the iMX-RT processors from NXP, I immediately thought: Cool! This is a very little board that offers great security features. And so I bought one. But when I played a litte with the board I determined, also with help of the forum, that the security features are unfortunately not accessible. Sure, for good reason from your point of view, but a lot of people including me are asking for those features. As you state, you intend to add those features in the future, probably, but there is no actual planning for that.
So what about if you get support at no cost to push development of security features? I have some experience with the High Assurance Boot (HAB) on iMX6, as I wrote a secure bootloader for this device for my company. The HAB on the iMX-RT seams to be not very different. So I know the troubles around the fuses its sparse documentation and the pitfalls of going wrong. I also have access to the security data sheets from NXP and I'm willing to share my insights and help you develop those features for your boards. What about this offer?
Hi Dresden-fx,
I hope you are able to make some progress on this. I really like the PJRC boards, but am not able to migrate to the 4.x family until someone get this working. My skills aren't a good fit for this at all, or I'd like to help.
Doug
Fellows, I'm a relative newb to this board, but it's been my personal experience that all you have to do to help is to share the code. I posted a ridiculously simple effect here and within a few days Paul had responded in the thread if he could use my code for his project. No problem. It's actually in there now (with his mods) AudioEffectRectifier. I became a member of this community and within a month or two I was a code contributor.
I second this. Paul and the community here are amazing at providing help to anyone willing to share code and follow up reasonably. Many of the amazing libraries that make Teensys so useful are contributed by community members. Many times Paul has gone as far as purchasing hardware to duplicate a customer issue.
I don't speak for Paul or anyone else here, but I can say for myself, I've been impressed and delighted on many occasions with the quality of the help here.
Thank you for sharing your insights in this forum and how contibutions are handled. I wish I could share some working code, but the problem here is, that the hardware as it is delivered today isn't in the condition to run secure code as the relevant fuses are burnt by paul's fixture, so that the hardware runs as "non secure" device. For High Assurance Boot to work it needs a device that can be "closed" after provisioning it with the hash of "super root keys" in order to become a "secured device". So in order to write some working code, that can be shared, it needs a device that is not locked when shipped.
Paul mentioned somewhere, that he could imagine to provide special boards with only those fuses burnt that are relevant for the hardware configuration, but security related fuses still open. He mentioned also, that those boards, if ever existing, will clearly be marked as such.
So the question to Paul is how much effort it takes to adapt his fixture, to not burn the security related fuses and whether he is willing at all to build those boards.
I would also like to discuss with him, whether he has any plans or ideas for code security and what degree of openness he can imagine imagine to provide for his chips, which definately depends on the prospective goals of his product and is thus dependent on various factors. So todays driving factor seams to be uncomplicated usability by the average killed user. That's also a reason why it is supported by the arduino IDE. A main goal seams to be, that the devices cannot be bricked easily by any mistaken code.
In my opinion it is not easy for a average experienced developer to mistakenly burn fuses so that the device gets bricked. The reason is that NXP / Freescale provided their chips with a special unlocking mechanism "In order to avoid rogue code performing erroneous writes to OTP" as they say. But on the other hand, if locks are left open, you definately can brick your device trying to burn fuses. Another way to brick your device is to provision it with a public key and loosing your matching private key. In this case you are no longer able to update the software.
So my suggestion is to provide a fool-proove solution, maybe a library or special firmware image, that allows the unexperienced user to perform the write of selected fuses with values that might be validated by the firmware/lib. This could be an option to prevent a lot of users destroying their devices when trying to apply secure boot.
A real life analogy is that you can by a car and if you, for example, try to perform a chip-tuning by yourself, you will probably brick your car, if you are not experienced and absolutely sure what you do. So if you want a chip-tuning for your car you need an experienced repair shop which has the proper tools to do the job. Also if you loos the keys to your car, you cannot drive it anymore. Anyway the manufacturers sell cars with all those options to brick it.
So having said all this, I hope Paul can answer to this thread.
I could use some help with HAB. Months ago, I spent some time trying to use NXP's CST program (version 3.3.0) to add the CSF to compiled images, and I burned the SRK hash into the fuses, but I never managed to get it working to the point where the logged events showed HAB successfully verified.
A first minor issue is the linker script we're currently using places "DMAMEM" and the beginning of the heap where HAB stores the logged events. At one point I created a modified linker script to reduce our OCRAM usage slightly, and modified the boot vector table with the address of the CSF. I created a simple program which uses the hab_rvt functions to query the logged events. Before sharing that, I really need to review whether posting it in public violates our NDA with NXP.
HAB is only one piece of this puzzle, but a critically important step. We need to be able to create a valid CSF that passes the HAB checks, so NXP's ROM will allow us to boot. We also need to be able to generate a tiny HAB-valid program which enables JTAG.
I could write much more on this, but I'm out of time for today. Hopefully this is at least a start.
This 20 page doc seemed to be readable without login :: nxp.com/docs/en/application-note/AN4581.pdf
There is a new CST 3.3.1 tool found that requires NXP login and then was available when registered :: IMX_CST_TOOL_NEW :: cst-3.3.1.tgzCode:AN4581 i.MX Secure Boot on HABv4 Supported Devices Rev. 4 — June 2020
Paul notes CST 3.3.0 - and the newest CST 3.3.1 may not be the right one for the T_4.x?
LOGIN NXP then search for "IMX_CST_TOOL":: nxp.com/search?keyword=IMX_CST_TOOL&start=0
1.4 Definitions, acronyms, and abbreviations ::Code:SOFTWARE i.MX High Assurance Boot Reference Code Signing Tool (REV 3.1.0) NXP® Code Signing Tool for the High Assurance Boot library. Provides software code signing support designed for use with i.MX processors that integrate the HAB library in the internal TGZ15.5 MB15 Oct 2018IMX_CST_TOOL SOFTWARE IMX_CST_TOOL_NEW (REV 3.3.1) NXP® Code Signing Tool for the High Assurance Boot library. Provides software code signing support designed for use with i.MX processors that integrate the HAB v4 and AHAB library in the internal TGZ9.7 MB17 Aug 2020IMX_CST_TOOL_NEW
Code:CSF Command Sequence File A binary data structure interpreted by the HAB to guide authentication operations. CST Code Signing Tool An application running on a build host to generate a CSF and associated digital signatures. HAB High Assurance Boot A software library executed in internal ROM on the NXP processor at boot time which, among other things, authenticates software in external memory by verifying digital signatures in accordance with a CSF. This document is strictly limited to processors running HABv4.
Thank you much for your reply, Paul. It shows that your really took some effort on this topic, which makes me quite happy.
You are right, but HAB is essential to further steps as only HAB creates a root of trust. Shure, there are other topics to follow, but a lot if not all are based on HAB / fuse provisioning.
Ok, did you really burn the SEC_CONFIG[1] fuse? I think to remember that for the i.MX6 I always got HAB events indicating authentication failure due to invalid address or similar. Getting in contact with the support team from freescale they told me that with the version of the ROM bootloader the HAB cannot be tested in "Open" secure configuration, but this may have changed for the i.MX-RT derivatives.
Yes, I did very similar and created a set of HAB API functions according to the "High Assurance Boot Version 4 Application Programming Interface Reference Manual" documentation contained in the CST package. Mine lets me also print information about the IVT and RVT.
Good point!
That should be possible by means of either using the JDE bit by the program code or by the DCD/CSF of the image. But why is it necessary? All the JTAG pins are connected to the boot chip (Kinetis). Does the boot work on JTAG protocol? I guess I need mor details about the boot and image update process. If I'm right, a new image gets into the MCU via the USB. Is it then using the NXP's Serial Download Protocol driven by the MCU's ROM bootloder or is there a piece of your own software residing in the MCU which receives a new image and programs it into flash? Just by writing down the sentence I realized that there must be some piece of software either as the SDP doesn't handle the storage to flash. So where does it come from?
Another question important for me is: Could prepare and ship a few boards with the relevant fuses not burnt for testing? So I will pay for it, but need your help to leave them open.
Yes, this document actually covers, I would say, about 99% of the HAB. And it is quite complete. Thanks for sharing it here. But my experience is that some tiny pieces must be searched in other documents and without those pieces you get stuck.
I think a newer version of the tool is not a problem. It may support features which are not supported by the ROM bootloader of the i.MX-RT device, but should support all the older features.
Are you sure? That's not what NXP's IMXRT1060 reference manual says (or seems to say).
Unless I've somehow misunderstood these words, my understanding is we can burn the SRK hash into fuses and create a CSF with the signature and the logged data in OCRAM should tell us whether the signature was valid.
I've seen this described in nearly every NXP document, specific guidance to check the HAB signature while still in open mode and to only burn the secure mode fuse once you have a valid HAB signature.
For the next Teensyduino beta, I will reduce the DMAMEM region slightly, so we aren't overwriting the HAB logfile in OCRAM. I'll also update the boot vectors with the CSF address. That will at least give us a better starting point.
Two big questions exist in my mind about what is or isn't covered by NXP's NDA (if anyone can download it publicly, then the NDA says it's not confidential)
1: Can anyone publicly download CST version 3.3.1 or 3.3.0 or any other version?
2: Can anyone publicly download the files HAB4_API.pdf and CST_UG.pdf? (which are in the "docs" folder when cst-3.3.0.tgz is extracted)
There are also 2 headers files, hab_defines.h and hab_types.h.
I found a public copy of hab_defines.h here:
https://github.com/RT-Thread/rt-thre.../hab_defines.h
I have a copy of hab_types.h in my code from months ago, and sadly I don't have any record of where I found it. The header file doesn't specifically say it's confidential. It does have this:
It anyone could find a copy of this header as a public download, that would go a long way towards being able to put test code on github.Code:#ifndef HAB_TYPES_H #define HAB_TYPES_H /*===========================================================================*/ /** @file hab_types.h @brief Constants, macros and types common to both external interfaces and internal modules. @verbatim ============================================================================= Freescale Semiconductor (c) Freescale Semiconductor, Inc. 2007-2016. Copyright 2017-2019 NXP Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met: 1. Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer. 2. Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution. 3. Neither the name of the copyright holder nor the names of its contributors may be used to endorse or promote products derived from this software without specific prior written permission. THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. ============================================================================= @endverbatim */
Yes, As noted in p#11 - with a 'registered user' login I downloaded the CST.
Extracted I see this::
And ::Code:T:\T_Downloads\cst-3.3.1 (2)\cst-3.3.1\docs>dir Directory of T:\T_Downloads\cst-3.3.1 (2)\cst-3.3.1\docs 08/14/2020 05:53 AM <DIR> . 08/14/2020 05:53 AM <DIR> .. 08/14/2020 05:56 AM 2,373,822 CST_UG.pdf 08/14/2020 05:56 AM 1,873,821 HAB4_API.pdf 08/14/2020 05:56 AM 4,280 README.hab_log_parser 3 File(s) 4,251,923 bytes 2 Dir(s) 447,495,716,864 bytes free
hab_defines.h file is NOT included.Code:Directory of T:\T_Downloads\cst-3.3.1 (2)\cst-3.3.1\code\cst\code\front_end\hdr 08/14/2020 05:56 AM 13,586 hab_cmd.h 08/14/2020 05:56 AM 42,373 hab_types.h 2 File(s) 55,959 bytes
Oh, that's very good news!
Does it also have a copy of hab_types.h in code/cst/code/front_end/hdr? File size should be 42373 bytes. MD5 should be 3fd303e7450e0f6a97d346b8250e3091.
I don't have MD5 handy - but updated post #16 matches location and size and I see this:
Code:Name: hab_types.h Size: 42373 bytes (41 KiB) CRC32: 32B4830E CRC64: 3C1830A58D5CFCF6 SHA256: 983A89913E681F149DCC3E515E812D382F6D730223FD463319EF8BEB7165CE74 SHA1: 6CA544B9F7C1EC19A2FC154CB458C90DD50DD908 BLAKE2sp: 46E04954CBFBA1FEFDD147CA7236091F7EA671731470C2A9EB29CA45A3BF7B31
... Here - the unsecure MD5 value I get is ::
How to Add Hash to Context Menu of Files in Windows 8 and Windows 10Code:Algorithm : MD5 Hash : 3FD303E7450E0F6A97D346B8250E3091 Path : T:\T_Downloads\cst-3.3.1 (2)\cst-3.3.1\code\cst\code\front_end\hdr\hab_types.h
Wow that adds others too:
Code:Algorithm : SHA1 Hash : 6CA544B9F7C1EC19A2FC154CB458C90DD50DD908 Path : T:\T_Downloads\cst-3.3.1 (2)\cst-3.3.1\code\cst\code\front_end\hdr\hab_types.h Algorithm : SHA256 Hash : 983A89913E681F149DCC3E515E812D382F6D730223FD463319EF8BEB7165CE74 Path : T:\T_Downloads\cst-3.3.1 (2)\cst-3.3.1\code\cst\code\front_end\hdr\hab_types.h Algorithm : SHA384 Hash : F745F534C3A5AADBDAB7F3BEE7188899EDD918BB0DC69D8B7C3DA2D86D9CBE669B35DA1EDBD0C3FFF527A698A1B23A86 Path : T:\T_Downloads\cst-3.3.1 (2)\cst-3.3.1\code\cst\code\front_end\hdr\hab_types.h Algorithm : SHA512 Hash : BB31846DD3873D0A06E131BF61B4B83DA80260DD7DE0D296E8F22C1B699C0CA699EBE2252BB30E97525A830AB4E7C568FE73E6646FE 8D4EC5DC04D5AC7BA4654 Path : T:\T_Downloads\cst-3.3.1 (2)\cst-3.3.1\code\cst\code\front_end\hdr\hab_types.h Algorithm : MACTRIPLEDES Hash : 3503DA869B6E9264 Path : T:\T_Downloads\cst-3.3.1 (2)\cst-3.3.1\code\cst\code\front_end\hdr\hab_types.h Algorithm : MD5 Hash : 3FD303E7450E0F6A97D346B8250E3091 Path : T:\T_Downloads\cst-3.3.1 (2)\cst-3.3.1\code\cst\code\front_end\hdr\hab_types.h Algorithm : RIPEMD160 Hash : 739B1B775946C1F1C192EEA1B958E21966481461 Path : T:\T_Downloads\cst-3.3.1 (2)\cst-3.3.1\code\cst\code\front_end\hdr\hab_types.h
When I did the implementation for the i.MX6 the reference manual made the very same statement. But as I did not get it work in "open" mode I got in contact with the support team, searched in forums and read a lot of appliction notes. Unfortunately I do not remember how exactly I got that information but this was obviously a bug in the ROM image and it was intended to work properly also in "open" mode but did not. Then when I had this information I needed to proof and I decided to burn that fuse and guess what: First restart with closed device went wrong and the board seamed to be bricked, really! Anyway, I cannot remember exactly how, but I was able to get access to the fuses, I guess by the debugger, as I did not lock out the JTAG access, an I had found a document that told that it is necessary to burn an obviously undocumented fuse and after burning it the image finally started with the processor in "closed" mode. Later I found out that this fuse was called the memory trim. And in today's documents there is a hint about that fuse, which is related to the RNG somehow.
So normally I would expect this bug in the ROM image has been fixed by Freescale / NXP in today's MCUs, but there is no evidence until one tried out.
What kind of error is reported in your HAB?
Contrary to previous versions of the documents (I have one of 2012) which stated "Freescale Confidential Proprietary" on every page, this statement is no longer given in the recent version.
Indeed no confidential or other markings on the 70 page:
Or the 73 page:Code:High Assurance Boot Version 4 Application Programming Interface Reference Manual COPYRIGHT 2018-2019 NXP
All that was done is to become a registered user that was needed to get the CST download with those docs.Code:Code-Signing Tool User’s Guide Rev. 3.3.1 07/2020 Copyright 2017-2020 NXP
Ok, I've create a repository on github with all of my work-in-progress HAB stuff.
https://github.com/PaulStoffregen/hab_tests
I wrote a readme file with (probably rough-around-the-edges) instructions. Your very first step should be to edit the linker script, and then run the teensy4_hab_logfile sketch. It will print a bunch of info. Here's what you should see.
The goal is to find a way to edit teensy4_hab.csf and all the rest of this stuff (and maybe the linker script and bootdata.c) so this program prints "no warning or failure audit events have been logged"....Code:High Assurance Boot API Test - Show Logged Events ------------------------------------------------- Unique ID: 65F82969 472D69D2 SRK Hash: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 Image Vector Table: (ref manual rev 2: 9.7.1.1, page 261) Header 402000D1 Vector 60002000 reserved 00000000 DCD 60001020 Bootdata 60001024 Self 60001000 CSF 00000000 reserved 00000000 Bootdata: (ref manual rev 2: 9.7.1.2, page 262) Start 60000000 Length 00009B98 Plugin 00000000 DCD: (ref manual rev 2: 9.7.2, page 262) TODO: parse and print DCD CSF: (is this data format documented anywhere??) No CSF (null) HAB Version: 00040307 failure event Failure: Invalid address: access denied in "hab_rvt.authenticate_image()" Failure: Invalid assertion in "hab_rvt.assert()" 32 bytes at 60001000 not authenticated Failure: Invalid assertion in "hab_rvt.assert()" 4 bytes at 60001020 not authenticated Failure: Invalid assertion in "hab_rvt.assert()" 1 bytes at 60001024 not authenticated Failure: Invalid assertion in "hab_rvt.assert()" 4 bytes at 60002000 not authenticated
Just to make sure I answer these questions....
Let's assume NXP / Freescale fixed this problem and their documentation on page 205 in the reference manual, and pretty much everywhere else in the HAB documentation is indeed correct for these relatively new IMXRT parts.
We're using the 1062 chip, which is the 2nd generation of IMXRT chip with an updated ROM compared to the original 1052 chip. I'm pretty sure this works in 1052, but if the bug did exist all the way up to IMXRT release, certainly NXP has had several opportunities to fix it.
I'm not going to mess with the Teensy 4 test fixture (which sets the fuses) until we can at least get the teensy4_hab_logfile to pass.
When/if we do get to that point, I can't promise anything specific. But from everything I know so far, that would seem like the next logical step. Right now, with never yet managing to create a HEX file which passes the HAB checks, that seems a long way off.
Now that I've published teensy4_hab_logfile.ino and all my other work-in-progress files, you can see the error. Calling hab_rvt.report_status() returns HAB_FAILURE, and calling hab_rvt.report_event() returns failures.What kind of error is reported in your HAB?
You can update the linker script and then use Arduino to upload this to your Teensy 4.0 or 4.1 to see the errors. You said you wanted to help, so I've shared all the work-in-progress files. The help I need at this point is figuring out how to craft the teensy4_hab.csf and all the other details so the final teensy4_hab.hex file runs on Teensy 4 and hab_rvt.report_status() returns HAB_SUCCESS.
Hopefully this gives you everything needed to help on the HAB stuff?
Ok, I have seen it and already checked out. I will try to see the results an hopefully make some progress on the CSF definition. I checked the format of writing the SRK fuses and compared to what I previously did they look fine.
Posting Permissions
Reply With Quote