Application Note

NG-ULTRA

bitstream loading security

Ver 1.0.0

Jan 2022

Table of Content

Release Notes

Document History

Related documentation

Acronyms

Summary

This application note, the reference designs and the associated scripts are intended to show NG-ULTRA FPGA bitstream loading security process.

Introduction

The NG-ULTRA component is composed of a large embedded FPGA and a digital processor subsystem based on ARM Cortex R52 cores. The bitstream manager (BSM) manages the FPGA fabric configuration.

Fig 1 – NG-ULTRA bloc diagram

NG-ULTRA FPGA bitstream security is managed through the implementation of encryption mechanisms applied to the data to be protected. Security function that encodes a digital data using a secret encryption key, making the encoded data unintelligible unless it is decoded using a decryption key.

Test environment

Tools

Hardware:

NG-ULTRA Bring-up board

Software:

• Nxmap

• Nxbase2

• Security loader test package tools reference designs, scripts and binary files

Install plugins NXBASE2 full options

Please install the plugins full options to enable the loading of BTS file with NxBase2.

Copy the directory full_options into the two directories:

• nxbase2_cli/plugins

• nxbase2_cli/nxbase2/plugins

Bring-up board set up

Bypass mode

Mode useful to test and debug, to bypass all security process.

Tab 1 – Bypass mode selection

Note:

• This mode can be control through Nxbase2 software (overwrite jumper setup)

• This mode is only available on NG-ULTRA V1

JTAG interface

JTAG interface is chained from the SOC to the FPGA and allow to debug the SoC code or to load a bitstream in the FPGA. On the bring-up board, the NG-ULTRA JTAG can be connected by the FPGA SPARTAN6 with the Nxbase2 commands or by the debug mictor interface with the lauterbach trace 32/debug probe or openOCD.

Tab 2 – JTAG master selection

Note:

• This mode can be control through Nxbase2 software (overwrite jumper setup)

• JTAG clock must be < configuration clock / 2

NG-ULTRA configuration mode

Tab 3 – Configuration mode selection

Note:

• 0 = jumper unset, 1 = jumper set

• This mode can be control through Nxbase2 software (overwrite jumper setup)

FLASH SPI configuration

Tab 4 – FLASH SPI configuration selection

Note:

• Internal flash selected, Flash_Num selects Flash 0, 1, 2 and 3 on board

• External flash selected, Flash_Num selects Flash 0, 1, 2 on board and Flash 3 external

• This mode can be control through Nxbase2 software (overwrite jumper setup)

Configuration clock

Tab 5 – Configuration clock selection

Note: When programming the Security OTP, the user should set the J20 to have the frequency BSM clock required to write into the OTP memory. (40MHz < clk BSM < 80 MHz)

SOC clock

Tab 6 – SOC clock selection

User clock

Tab 7 – User clock selection

Bring-up board LED

Tab 8 – Bring-up board LED

Note: At power ON, all voltage LEDs have to be lighted.

Bring-up board user GPIOs

Tab 9 – Bring-up board user GPIOs

Note: User GPIOs are activated low

Bitstream download process

To configure the fabric, the BSM uses rows of drivers. Each driver row manages a subset of logical rows. Each driver row is managed by a Loader module. This Loader module includes all FSM to access to configuration memory.

A bitstream is a collection of Frames. Each frame as a header and a body. Frame header is a 32b word protected by EDAC. A bitstream includes 2 CRC, Frame CRC that checks the integrity of each fabric configuration frame and Bitstream CRC that checks the integrity of the whole bitstream.

Fig 2 – BSM bloc diagram

The BSM is composed of several I/O controllers:

• JTAG interface with dedicated IOs

• PAREXT (16b parallel) interface with dedicated IOs

• PARUSR(16b parallel) interface connected to the Fabric

• AHB slave interface connected to the SOC

Each controller is connected to 2 engines bloc to access the loaders:

• Frame engine is used to fabric configuration to manage bitstream format. It’s frame access

• Direct engine is used to debug and test to manage address, data format, not encapsulated in a bitstream. It’s direct access

The security module is in charge of:

• Accessing OTP memory that contains all security information and identification value.

• Controlling accesses depending on lifecycle

• Decrypting the bitstream

• Checking the bitstream authentication

Test_001 is an example of loading a non-encrypted bitstream with security mode enabled and disabled.

Loader OTP memory

The loader OTP stores security related data such as keys, seeds for key generation, identifier, anti-rollback counter, secure mode configuration.

Tab 10 – Loader OTP memory contains

Note:

• Before accessing the OTP memory, it will be bisted and the OTP supplementary address 0x3 and 0x4 must be written with value 0x5555 and 0xAAAA respectively

• When programming the Security OTP, the user should be careful to have the main configuration clock, CLK_BSM between 40 and 80 MHz

• The user should be careful to program the OTP ECC-protected fields only once. If an ECC6 protected field is programmed multiple times, there’s a great chance that the ECC signature becomes unreadable and ends up ‘bricking’ the chip by generating a DED error upon booting

• Some data are masked with the key masking seed before writing into the OTP memory

Test_002 bist the loader OTP memory.

Test_003 program the supplementary address to get the write access to the OTP and program the OTP identifier as IDCODE and ICID.

Test_004 dump the OTP memory.

Lifecycles

The lifecycle value is stored in the OTP memory. It determines the bitstream configuration interface and the type of BSM accesses authorized and the type of bitstream (crypted or encrypted).

Fig 3 – Lifecycle diagram

Note: In order to write a lifecycle in the OTP, the user should make sure that the OTP user code, ICID are already written.

Lifecycle interfaces and accesses

Tab 3 – Lifecycle interfaces

Note: The direct access is proceeded by direct engine with BTS file and the frame access is proceeded by frame engine with BBS or NXB file.

Anti-Rollback

A cyphered bitstream contains the rollback counter. Deciphering engine compares it to the anti-rollback counter stored into the OTP memory. The check algorithm depends of the life-cycle.

Tab 12 – Lifecycle anti-rollback check

Test_005 program the security data, lifecycle data, encryption keys and anti-rollback counter.

Bitstream encryption

Depending on the lifecycle, the encryption must be used to properly load a bitstream.

Bitstream encryption step:

• Nxmap has to generate a bitstream in BBS format file

• Remove the comments into the .BBS file to simplify the following padding step

• Some informations should be added at the beginning of the .BBS file

  • Rollback counter (128b)

  • TAG (128'h2e90_0db0_07ab_7eac_ce55_c0de_de7e_c7ed)

  • Size of the bitstream + padding words expressed in number of 32b word (128b)

  • Bitstream payload

  • Padding words

• Run the encryption script Utils/Encryption/bitstream/encrypth.sh

Note:

• Cyphered bitstream is constituted of 128b frames whereas uncyphered bitstream contains 32b frames. To match size, uncyphered bitstream must be padded to 128b with dummy data inserted after the uncyphered bitstream

• There are 0, 1, 2, or 3 padding word maximum

Example:

Bitstream BBS file without comments:

12345678

01e061da

00000001

6001988d

cacababe

e0001c28

94f59cd2

Bitstream BBS file modified before encryption:

0000000000000000000000000000000 -> ROLLBACK COUNTER

2e900db007ab7eacce55c0dede7ec7ed -> TAG

00000000000000000000000000000008 -> Size of the bitstream + Padding words

12345678 (7*32b words + 1 padding=8*32b words)

01e061da

00000001

6001988d

cacababe

e0001c28

94f59cd2

00000000 -> padding word

Encryption script command:

./encrypt.sh –input_folder=. --key_enc=7625412a7625412a7625412a7625412a

--key_mac=7625412a7625412a7625412a7625412a

Encrypted bitstream BBS file:

12345678

00000000

00000000

00000000

feedb0a5

ec7edd07

1abe15e1

2efacade

00000000

00000000

00000000

00000000

00000000

00000000

00000000

00000000

6ceecd01

1b31513e

9b6b2a3a

dc803c91

2b1af62b

c97aedcd

5cc3dbf3

ae9e5210

bdd846d9

ff9f1d65

c5446ab4

b2cd4d09

2f5e5e5d

5b01e618

8bae17f8

fb36b169

79780431

ea48e29e

4f64fd7e

f682c447

90e7e237

613e643c

8b27c27c

b8560fc4

Test_006 is an example of loading a crypted bitstream.