Hello,
Could you tell us the way to protect Jetson Nano from reverse engineering?
Please image the situation after mass production.
Some malicious people may open the product, remove the Jetson module from the carrier board and then attach the module to their own carrier board.
In this case, they can boot the Jetson module in our products, read our software and steal our own technology.
So, we want to know the method to avoid this reverse engineering.
Best Regards,
NY
hello nomoto-y,
Jetson Nano series only support secureBoot,
please also refer to https://developer.nvidia.com/embedded/learn/tutorials#developerTools page, here’s Jetson Security and Secure Boot, it shows an overview of security features.
thanks
There isn’t really a good way to prevent this (on any platform). Time spent on attempting this feat is probably wasted. Would suggest saving the money for lawyers to block such an adversary from trying to sell their product in your market. Even Trusty has issues and even Nintendo failed to secure their Tegra variant (this is not specific to Tegra, it’s just an example of DRM being pointless. Nintendo has some of the best engineers and they can’t manage).
Secure boot is a good idea to make sure your kernel, modules, etc are tamper-resistant, and filesystem encryption can help secure data, but I don’t think it’s possible to prevent copying stuff as you suggest. At some point your thing is going to be decrypted and at some point a vulnerability is going to be found in something you rely on. You can possibly attempt to have all your devices “phone home” and require security updates periodically, but that’s possible to circumvent as well and might just frustrate your users when they have connectivity issues.
Hi mdegans-san,
Thank you for your reply.
It’s very helpful information for us.
Best Regards,
NY
@mdegans is very much correct, but I’ll add something which might help…it definitely would not be useful by itself…
Much of the hardware enforced security is for the chain of boot. The rootfs has no such security. If you were to encrypt the rootfs, then one could not simply copy it via a tool like dd or recovery mode clone without it still being encrypted. Protecting the key for encryption is one obvious “part” of a solution, but all bets are off once the encrypted system is actually booted. Ordinary file copy could then copy anything the user has privileges for. Presumably root would be possible via sudo, so an already decrypted filesystem has a lot of vulnerabilities for anyone with sudo access.
I’ve not seen SElinux used with a Jetson. What SElinux does is reminiscent with having two separate accountants whereby both accountants would need to work together to do any “cooking of the books”. Not only does a user need to have file permissions to perform certain operations, that user must also be defined as having the “role”. A user could use sudo to edit files in a root-only directory, but unless the user were also defined as being in an authorized role, this would still be denied. You might for example be able to create a user which only your company has access to, and that user would be the only one capable of certain file operations.
If SElinux is enabled at boot the kernel will refuse to disable it. If your boot chain is hardware enforced through boot configuration to not allow editing, then you more or less have guaranteed that SElinux cannot be turned off without either (A) the keys used in the trusted chain of boot, or (B) having a user on the Jetson defined for some security operation. There would be a lot you would have to learn for using SElinux, and it can interfere in unexpected ways (especially if using default Ubuntu roles…probably you would start with that and then edit this). In theory though this would be the next step up beyond secure boot content and filesystem encryption if you are willing to put a lot of work into learning this.
I don’t know if SElinux labels would have any effect on booting a Jetson. I am guessing that having SElinux labels would not interfere with boot, but you’d probably need to be sure any such labels exist at every stage of boot where the Linux kernel runs. I couldn’t say for certain if SElinux would work on a Jetson, it would be an experiment.
Hi linuxdev-san,
Thank you for your reply.
We’ll refer your comment.
Best Regards,
NY