IP Protection

IP Protection is TinyCLR's set of features for keeping your intellectual property — your application code, keys, and sensitive data — unreadable on shipped devices. Combined with Secure Boot, TLS, and Secure Storage, it gives you a defensible posture against reverse engineering, key extraction, and code theft.

The protection comes in two parts: protecting your code at rest, and protecting your data at runtime.

Threat model

What IP Protection defends against:

• Reading your application code off the device via the debug interface
• Reading code stored in external QSPI flash by probing the flash chip directly
• Reading sensitive data from external RAM

What it can't defend against:

• Compromising a key that you embed in your application source — keys baked into the code are only as safe as the protection of the code itself; rotate keys via In-Field Update when needed
• Attacks against the Bootloader — anyone with physical access can force the device into bootloader mode and Erase All, but doing so wipes the protected application without revealing it

Securing user code

Internal flash by default

Your application code lives in the SITCore's internal flash, which isn't accessible from outside the chip. The only paths into it are:

• The USB or serial debug interface — open during development, normally disabled in production
• The bootloader — which can erase but not read

Disabling the debug interface

In production, disable the debug interface so a physical attacker can't read out your code via Visual Studio:

using GHIElectronics.TinyCLR.Native;

DeviceInformation.SetDebugInterface(DebugInterface.Disable);

This can also be done from TinyCLR Config without writing code.

warning

DebugInterface.Disable can only be undone by a full Erase All from TinyCLR Config or the bootloader. That wipes the application along with the setting. Plan firmware updates via In-Field Update instead — Disable is one-way for the deployment, not for the device.

When the debug interface is disabled:

• The APP and MOD special pins become inactive
• Visual Studio can no longer deploy or debug
• The current state can still be read with DeviceInformation.DebugInterface

Secure assemblies (for code in external flash)

When you extend the deployment region into external QSPI flash, the assemblies stored externally can be physically probed off the chip. To protect specific assemblies, mark them as secure — the deployment system will then place them in internal flash regardless of the extended region setting.

Edit AssemblyInfo.cs (under the project's Properties folder) and change:

[assembly: AssemblyConfiguration("")]

to:

[assembly: AssemblyConfiguration("secure")]

The word secure is not case-sensitive.

During deployment, Visual Studio's TinyCLR Device Deployment output window shows an allocation table indicating which assemblies landed in secure (internal) flash and which went to external — a quick way to verify your secure assemblies ended up where you expected.

Securing data

Internal RAM

By default, the entire managed heap lives in the SITCore's internal RAM — keys, cryptographic state, decrypted payloads, everything. Internal RAM isn't probable from outside the chip, so anything there is safe from physical attack.

External RAM and SDRAM

External SDRAM is used for the graphics engine and for explicit UnmanagedBuffer allocations. Both are deliberately exposed to potential probing — but the typical contents (display framebuffers, large media buffers) aren't sensitive:

• Graphics buffers contain rendered images. Usually nothing private — unless your UI shows a key on screen.
• UnmanagedBuffer is your conscious choice to put data in unsecured memory. Use it for bulk data that doesn't matter if read, not for secrets.

Extending the managed heap into external SDRAM

If your application needs more managed RAM than the SITCore's internal memory provides, you can extend the heap into external SDRAM — but this puts your managed data (including potentially-sensitive state) into unsecured memory.

warning

Extending the managed heap into external SDRAM trades security for capacity. Don't do this if you handle keys, credentials, or other sensitive data — keep those in internal memory.

That said, external SDRAM isn't trivially probable the way external QSPI flash is. SDRAM is dynamic and needs continuous refresh; cold-chip readout is harder than reading a static flash chip. It's not secure, just more annoying to attack than external flash.

See External Memory for the heap-extension API and the trade-off in more depth.

API reference

Namespace	Description
GHIElectronics.TinyCLR.Native	IP protection and secure assembly configuration