Can't enable JTAG lockdown

[gtf35]

Expected Behavior

configure.py --lock-device
info: Device is now locked down!

Actual Behavior

configure.py --certificate=crypto_data/opensk_cert.pem --private-key=crypto_data/opensk.key --lock-device
info: Certificate is valid.
info: Programming OpenSK device
info: Please touch the device to confirm...
error: Failed to configure OpenSK (lockdown conditions not met or hardware error).

Steps to Reproduce the Problem

1. setup.sh
2. deploy.py --board=nrf52840_dongle_opensk --opensk --programmer=pyocd
3. configure.py --certificate=crypto_data/opensk_cert.pem --private-key=crypto_data/opensk.key
4. configure.py --certificate=crypto_data/opensk_cert.pem --private-key=crypto_data/opensk.key --lock-device

Specifications

• Version: 2.1 (commit: 893faa5113f47457337ddb826b1a58870f00bc78)
• Platform: nRF52840 dongle

[kaczmarczyck]

This issue is indeed not well documented. We heard that on the nrf52840 version we worked with, the lock down can be circumvented. Therefore, I made the command error instead of giving a false sense of security, see #620:

        #[cfg(not(feature = "std"))]
        {
            matches!(
                crp::set_protection(crp::ProtectionLevel::FullyLocked),
                Ok(())
                    | Err(TockError::Command(CommandError {
                        return_code: EALREADY,
                        ..
                    }))
            )
        }
        #[cfg(feature = "std")]
        {
            true
        }

became a simple false.

We could re-enable the old behavior so users with a new version of the hardware can benefit from it.

@jmichelp Opinions?

[jmichelp]

That would need more tweaking because to fix the bypass, Nordic made changes to the way the JTAG lockdown works.
So we would need to add code to support the newer versions of the chip as well as issuing a warning for old revisions that the lockdown could be circumvented.
And that also means we need to ensure we have such a revision of the chip to do some testing :)

[gtf35]

I think you did the right thing.

If it cannot be truly locked, it is correct to report an error.

We could re-enable the old behavior so users with a new version of the hardware can benefit from it.

Sounds good, looking forward to it

[kaczmarczyck]

This is not going to happen soon. I'll keep this issue open, steps to fix this include:

• A mechanism to tell apart the different versions of Nordic chips.
• The code necessary to correctly lock new chips.
• Warning and documentation for older chips.
• Testing to make sure a lock command does indeed disable debugging interfaces.

[rayc345]

The Nordic chips currently used is not designed to be secure MCUs such as those used in SIM Bank card.
Is there any plan to made a specific OpenSK hardware using a highly secure MCU?

[jmichelp]

Secure elements typically doesn't play well with open-source because of their common criteria certifications. So it's unlikely that we would be able to release a ready to use firmware for such a chip.

That being said, the current code should allow you to write an Env for the secure element you're planning to use (provided it's ARM or RISC-V based so that you can compile Rust for it) and leverage the hardware accelerated cryptography for the chip.
Think about OpenSK as a library you can instantiate for your platform, where Env tells OpenSK how to interact with the operating system you're using for that chip, which doesn't need to be Tock.