Coprocessor for cryptographic operations

Abstract

Certain embodiments described herein relate to a coprocessor that enables a processing unit to efficiently perform cryptographic operations. The coprocessor has an arithmetic calculation unit configured to perform discrete binary calculations using bit sequences loaded from memory. The coprocessor may be configured for fast, low-power calculation of specific functions that comprise the low-level building blocks for cryptographic operations. These functions may include Boolean logic and integer arithmetic calculations. The coprocessor has a set of control registers that are writable by the processing unit to control the coprocessor. Addresses for one or more sources and destinations may be calculated by the coprocessor to enable flexible calculations. The coprocessor can enable many advanced cryptographic operations to be rapidly calculated, including those that are "post-quantum" secure.

Description

[Technical field]

[0001] The present invention relates to cryptographic hardware, and in particular to a co-processor for performing cryptographic operations. The co-processor may be used as part of a cryptographic system-on-chip. A method for performing cryptographic operations is also described. [Background technology]

[0002] In recent years, the number of devices connected to computer networks has exploded. For example, Internet connectivity has expanded beyond computing devices such as desktop and laptop computers to embedded systems in everyday objects such as automobiles, light bulbs, refrigerators, medical devices, thermostats, and monitoring systems. Telecommunication links enable many low-cost computing devices to report sensor data and / or be controlled throughout the world. One problem with those connected devices is that they are often vulnerable to attack and malicious control. For example, hundreds or thousands of embedded devices can be compromised by a malicious party and used to establish a distributed denial of service attack. In many cases, control of those devices is easily gained due to poor or limited implementation of encryption protocols. As those connected devices grow in number and prevalence, there is an open question of how to secure them.

[0003] Another consideration when securing connected computing devices is the possibility of subsequent attacks using quantum computing. For many years, quantum computing has been of primary theoretical interest. However, the implementation of quantum computing research is developing rapidly. Quantum computers with 50 and 72 qubits are currently available, and there are many research groups actively working on higher qubit machines. Assuming the possible future reality of quantum computing, recent studies have shown that many known public key encryption systems can be broken by a sufficiently powerful quantum computer.

[0004] When implementing cryptographic functions, especially those that are "post-quantum" secure, a challenge exists in that many of those functions are resource intensive. For example, many cryptographic functions involve complex mathematical functions using values ​​with long bit lengths. They typically consume a large number of processor cycles and present difficulties for implementation in low-resource embedded devices. In addition, as end-to-end encryption of both data and communications becomes commonplace, those cryptographic functions also need to be executed repeatedly and at high speeds. To be secure, they become slow.

[0005] US2008 / 0019524A1 describes an apparatus for a low-power AES encryption circuit for an embedded system, which includes an interface circuit for inputting and outputting data and control commands in cooperation with a general-purpose processor, a code processing unit for performing rounding operations in the operation sequences of an add-round key operation, a sub-byte key operation, a shift row operation, and a mix column operation, a data memory for storing data input through the interface circuit and for storing operation results processed in the code processing unit, a data selection unit for selecting data input / output to / from the code processing unit and the storage unit, and a control unit for controlling the code processing unit, the storage unit, and the data selection unit such that a rounding operation of a set rounding is repeatedly performed on the data input from the interface circuit, and an add-round key operation is performed on the result value and the secret key that have been shift row operated during the last rounding.

[0006] It is desirable to provide efficient implementations of cryptographic operations, for example implementations that can be used in low-resource embedded systems and / or in high-speed data processing operations, while providing attack resistance in post-quantum environments. Summary of the Invention [Means for solving the problem]

[0007] Aspects of the invention are set out in the accompanying independent claims, with particular modifications of the invention then being set out in the accompanying dependent claims.

[0008] Embodiments of the invention will now be described, by way of example only, with reference to the accompanying drawings, in which: [Brief description of the drawings]

[0009] [Figure 1] 1 is a schematic illustration of a co-processor for cryptographic operations according to an embodiment; [Diagram 2]1 is a schematic illustration of a cryptographic system-on-chip according to an embodiment; [Diagram 3] 1 is a schematic illustration showing a co-processor for cryptographic operations coupled to a system bus in a computing device, according to an embodiment. [Figure 4] 4 is a schematic illustration showing the operation of an arithmetic calculation engine according to an embodiment; [Figure 5A] 1 is a schematic illustration of a multi-dimensional data array according to an embodiment; [Figure 5B] 4 is a schematic illustration showing how an arithmetic computation unit can be applied iteratively to a set of multi-dimensional data arrays, according to an embodiment; [Figure 6] 4 is a schematic illustration of how source data can be shifted relative to the input according to an embodiment; [Figure 7] 2 is a schematic illustration showing how a main processing unit and an auxiliary processing unit can access data through a system bus according to an embodiment; [Figure 8] 1 is a table illustrating a set of control registers for an embodiment. [Figure 9] 4 is a flow chart illustrating a method for performing a cryptographic operation, according to an embodiment. [Figure 10] 1 is a table for use with Boolean operations of an embodiment. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0010] Certain embodiments described herein relate to a coprocessor that enables a processing unit to efficiently perform cryptographic operations. The coprocessor has an arithmetic computation unit configured to perform discrete binary arithmetic computations using bit sequences loaded from memory. Those bit sequences may be blocks of bits, and thus the coprocessor may be referred to as a form of "blitter", i.e. a hardware-assisted system for moving and manipulating blocks of bits in memory (the term "blitter" originates from "BitBLT" - Bit Block Transfer - a microcode instruction of the Xerox Alto computer). The coprocessor may be configured for fast, low-power computation of specific functions that comprise low-level building blocks for cryptographic operations. Those functions may include Boolean logic and / or integer arithmetic computations. Thus, the processing unit may effectively offload resource-intensive computations for cryptographic operations to the coprocessor, which operates as a dedicated and secure hardware device. The coprocessor may provide low-level bit operations that are atomic from the point of view of the processing unit. Thus, the coprocessor may enable many advanced cryptographic operations to be computed rapidly, including those that are "post-quantum" secure.

[0011] In certain embodiments described herein, the coprocessor may be used in a wide variety of computing systems, from internet servers to embedded devices. In one implementation, the coprocessor may be provided as part of a broader cryptographic system-on-chip (SoC), which may enable many low-cost embedded devices to implement "post-quantum" cryptography and provide a "post-quantum" secure system. For example, the functions implemented by the arithmetic engine of the coprocessor may enable code-based or lattice-based cryptographic operations to be performed rapidly, for example, by offloading many common low-level binary logic functions such as integer addition, subtraction, and multiplication. The coprocessor may be configured or preprogrammed with a set of available functions that can be selected by a processing unit via a function flag or variable in a control register of the coprocessor. The coprocessor may be able to compute certain functions more rapidly by avoiding the need to load and interpret separate instructions as required by the processing unit. For example, the set of available functions may be hard-configured in a programmable microcircuit and may be configured to access data in an array of source and destination registers, with the data being fetched and stored based on memory addresses generated by an address generator for each iteration of the arithmetic engine. Cryptographic processors can be particularly beneficial when used by embedded and resource-constrained targets.

[0012] FIG. 1 illustrates an embodiment 100 of a cryptographic coprocessor 110. In FIG. 1, the cryptographic coprocessor 110 includes a set of control registers 115, a control logic 120, an arithmetic engine 125, and an address generator 130. The cryptographic coprocessor 110 may be implemented using a programmed field programmable gate array (FPGA) or an application specific integrated circuit (ASIC). The components of the cryptographic coprocessor 110 may be configured using a hardware description language (HDL). In certain cases, different components of the cryptographic coprocessor 110 may be implemented using one or more of dedicated logic circuits, ASICs, FPGAs, and firmware instructions. In one case, the functionality of the cryptographic coprocessor 110 may be provided via one or more of a microcode update and a firmware update. In this case, authentication of the microcode may be required to ensure security.

[0013] The cryptographic coprocessor 110 is designed for use by an external processing unit or a main processing unit. This is shown in the embodiment 200 of FIG. 2, in which the cryptographic coprocessor 110 is communicatively coupled to a central processing unit (CPU) 220 via a system bus 230. The system bus 230 may include one or more of a data bus and an address bus. The embodiment 200 of FIG. 2 shows the cryptographic coprocessor 110 and the central processing unit 220 forming part of a cryptographic system-on-chip 240, which may be embedded in devices ranging from smart cards to server boards. Alternatively, the cryptographic coprocessor 110 may form part of a motherboard of a computing device such as a server, laptop, tablet, or smartphone. The CPU may include a microprocessor having one or more processing cores. The CPU may include a reduced instruction set computer (RISC) processor, for example a RISC-V processor.

[0014] In an embodiment, one or more of the cryptographic coprocessor 110 and the cryptographic system-on-chip 240 may be provided (e.g., packaged) as a discrete unit. For example, the discrete unit may be a self-contained security microcontroller (e.g., provided as a smart card, a Universal Serial Bus (USB) device, and / or a Radio Frequency Identification (RFID) device), an auxiliary cryptographic module or accelerator, a cryptographic trusted platform module (TPM) or a hardware security module (HSM). In a particular embodiment, the cryptographic coprocessor 110 and the CPU 220 may be co-located on a circuit board. Thus, one or more of the cryptographic coprocessor 110 and the cryptographic system-on-chip 240 may be provided as a single chip that is easily attached to additional computing boards for a wide variety of computing devices.

[0015] Returning to FIG. 1, the control registers 115 are accessible to an external processing unit (e.g., CPU 220). The external processing unit can write data to the control registers 115 to control the operation of the cryptographic coprocessor 110. The control registers 115 may be memory mapped such that they appear as an addressable portion of memory to the external processing unit. Alternatively, they may form part of a so-called single instruction multiple data (SIMD) or vector register set of the external processing unit. In a RISC instruction set architecture (ISA) such as RISC-V, the control registers 115 may be implemented as one or more control and status registers (CSRs) and / or one or more vector extensions, e.g., in the latter case the control registers may be viewed as one or more vector registers. A set of control registers may be used to exchange data and control information between the cryptographic coprocessor 110 and the external processing unit. Control registers 115 may be used to store one or more of the following: a status (e.g., busy or waiting for instruction), a function to execute, a size of the source data and / or destination data, a memory location for the source data and / or destination data, a shift parameter, an increment parameter for one or more of the address and data arrays, and / or an indicator of whether the current function is complete. The external processing unit may be configured to read the value stored in the control register 115 to determine whether the output of the function is available, may receive an interrupt from the cryptographic coprocessor, and / or may wait a predetermined number of clock cycles associated with the function. Different approaches may be used depending on the implementation requirements.

[0016] In the embodiment of FIG. 1, the control logic 120 reads values ​​written by an external processing unit into the control registers 115 and controls the operation of the arithmetic engine 125 and the address generator 130 based on those values. One of the sets of control registers 115 may be configured to store an indication of a function to be executed using the arithmetic engine 125. The function may be selected from a set of available functions, which may be preconfigured (e.g., preprogrammed into or configured within an ASIC or FPGA). The set of available functions is configured to operate on one or more bit sequences read from a data source (hereinafter referred to as "source") and store the result of the operation as destination data (hereinafter referred to as "destination"). For example, the set of available functions may include certain integer arithmetic functions frequently used by post-quantum cryptography methods such as lattice-based or code-based cryptography methods. Integer arithmetic functions may include multiplication, addition, and subtraction operations performed on one or more bit sequences considered as representing integer values ​​(e.g., 8-, 16-, or 32-bit integers). When Boolean operations are performed, the bit sequences may represent integer values ​​but may be treated as sequences of independent bits (e.g., for bit logic). Values ​​of different bit lengths may be supported. The arithmetic engine 125 may be controlled by the control logic 120 to perform a function indicated in the control register 115. The indicated function may be performed on binary data stored in a set (e.g., a plurality) of source registers, and the output of the function may be stored in at least one destination register. The set of source registers may be considered as the above-defined "source" for the function, and the at least one destination register may be considered as the above-defined "destination" for the output of the function.The source and destination registers may form part of the arithmetic engine 125 and / or may comprise specific locations within the internal memory of the cryptographic co-processor 110.

[0017] In one case, the control logic 120 may include one or more additional registers that can be used to store values ​​read from the set of control registers. For example, if the set of control registers 115 is memory mapped into the address space of an external processing unit, a secondary set of control registers may be used to speed up operations. This secondary set of control registers may not be accessible to the external processing unit, but instead is used internally by the cryptographic coprocessor 110. In this case, when a new operation begins, one or more values ​​in the set of control registers 115 may be copied to the secondary set of control registers. This may avoid the need to reinitialize the set of control registers 115 for every operation. The secondary set of control registers may be used to store a set of "running addresses." For example, if an operation is copying a small block of data to multiple destination addresses, the destination address parameters only need to be updated, and the operation may be started individually for each updated set of destination address parameters.

[0018] In practice, control logic 120 may include (system) bus control logic and chip select logic as well as signaling to reset cryptographic co-processor 110. In a particular implementation, it may also include logic to generate one or more interrupts to an external processing unit. One function of control registers 115 and control logic 120 may be to provide an interface between the internal logic of cryptographic co-processor 110 and the main system bus and external processing units.

[0019] The address generator 130 is configured to determine a set of source addresses used to load binary data from memory into a set of source registers, and at least one destination address used to store binary data from at least one destination register in memory. The memory may include an internal memory of the cryptographic coprocessor 110 or an external memory communicatively coupled thereto. The address generator 130 may determine the source and destination addresses based on values ​​stored in the control registers 115. The values ​​may include a starting address and parameters that indicate how to navigate through the memory. In one embodiment, described in more detail below, the cryptographic coprocessor 110 may be configured to operate on a multi-dimensional representation of data in memory and to store the results of the function in memory as a similar multi-dimensional representation. For example, a sequence of memory locations starting from a starting address may be thought of as a flattened matrix of height and width as defined by the value in the control register 115. In one case, when the arithmetic engine 125 applies a function that does not operate on all available sources, source addresses may be determined only for a subset of the available sources. For example, address generator 130 may include separate logic for each available source, in which case only the logic associated with the set of sources used may be activated to determine the set of source addresses.

[0020] FIG. 3 illustrates a further embodiment of a computing device 300 using a cryptographic coprocessor 310. The computing device 300 may form a standalone computing device or may include a system-on-chip implementation as shown in FIG. 2. The cryptographic coprocessor 310 is configured in a manner similar to the embodiment 100 of FIG. 1. The cryptographic coprocessor 310 includes a set of control registers 315, a control logic 320, an address generator 325, and an arithmetic calculation unit 330. In the embodiment 300 of FIG. 3, it also includes an internal memory 335. Both the control registers 315 and the internal memory 335 are coupled to a system bus 340 for the computing device 300. It should be noted that FIG. 3 is provided by way of example only and different implementations may include different components or combinations of components than those shown.

[0021] Along with the cryptographic co-processor 310, the computing device 300 also includes a CPU 350, a random access memory (RAM) 355, an electrically erasable programmable read-only memory (EEPROM) 360, one or more input / output interfaces 365, a random number generator 370, and possibly other cryptographic modules 375. The CPU 350 may include a RISC processor. The EEPROM 360 may be implemented as any programmable memory and may be configured to store operating computer program code for the computing device 300, for example, including a flash memory storing firmware for an embedded device or a system-on-chip. The RAM 355 may include a primary memory for the CPU 350. The one or more input / output interfaces 365 may include, among others, network and communication interfaces, as well as peripheral interfaces. The random number generator 370 and other cryptographic modules 375 may each include specific microcircuits that generate true random numbers and perform defined cryptographic algorithms (e.g., SHA-3, AES, etc.). They may be implemented in a similar manner as the cryptographic coprocessor 310, for example as a specific chip, a programmed FPGA or an ASIC. The components of the computing device 300 may exchange data via a system bus 340 and / or wired electrical couplings.

[0022] In the embodiment 300 of FIG. 3, the control registers 315 and the internal memory 335 of the cryptographic co-processor 310 are accessible to the CPU 350. For example, the control registers 315 and the internal memory 335 may be configured as memory-mapped resources for the CPU 350. In this case, the CPU 350 may read data from and write data to the control registers 315 and the internal memory 335 in a manner similar to the RAM 355 and / or the EEPROM 360. In one case, the set of control registers 315 and the internal memory 335 may be mapped into a secure address space of the CPU 350, e.g., an address space that is not accessible to non-root, non-management, or user processes. This may help secure the operation of the cryptographic co-processor 310. Although the set of control registers 315 and the internal memory 335 are shown as separate components in FIG. 3, they may be implemented by a common set of memory accessible to the CPU 350 (e.g., implemented as different ranges of addresses in memory).

[0023] The cryptographic coprocessor 310 may additionally be protected using security fuses and / or side channel attack countermeasures. The security fuses may prevent unauthorized access to the cryptographic coprocessor 310 memory that stores the operating firmware and microcode, etc. For example, the control circuitry, sensitive arithmetic and computation operations, and other components may be protected by logical or physical countermeasures that prevent or shield the leakage of secret information via electromagnetic emissions, fluctuations in power users, operation timing, or other unintended side channels. In one case, a physically secured enclosure (for the coprocessor) and / or guard logic may be used to detect unacceptable or malicious fluctuations in operating conditions, such as input voltages or signals. The circuitry may also use error detection and correction to ensure fault detection and correction. Upon detection of such an error condition, further operation may be prevented via a security fuse mechanism. The coprocessor may also be configured to immediately erase any secret information contained in its internal memory, such as a private key.

[0024] In the embodiment 300 of FIG. 3, the address generator 325 is configured to determine multiple source and destination addresses in the internal memory 335 during a given iteration of the arithmetic engine 330. The internal memory 335 may be filled with data to be used to perform a defined number of iterations of a function to be executed by the arithmetic engine 330, and the address generator 325 may determine a different set of source and destination addresses for each iteration. The arithmetic engine 330 may be configured to read or fetch data from the multiple source addresses as determined by the address generator 325 prior to the calculation of the function. The arithmetic engine 330 may then store the result of the calculation at the destination address. In certain cases, the arithmetic engine 330 may read data from and write data to a set of temporary registers or a cache in which data can be stored as part of a memory transfer. The CPU 350 may be able to read the results of the calculation by accessing the destination address in the internal memory 335, or may wait until several iterations are completed and read data from multiple destination addresses, e.g., a defined block of the internal memory 335.

[0025] FIG. 4 shows an example embodiment 400 of how an arithmetic engine can process data as indicated by an address generator. FIG. 4 shows portions of control logic 420 that control address generator 425 and arithmetic unit 430. Although two portions are shown for clarity, they may form part of a single piece of control logic or circuitry. In this example, arithmetic unit 430 processes a bit sequence read from memory 435 using a memory address 450 determined by address generator 425, and outputs a resulting bit sequence stored in memory using a memory address 455 also determined by address generator 425. In this example, arithmetic unit 430 includes three source registers 460 and one destination register 465. These are shown as internal registers of arithmetic unit 430, but may instead include a pipeline cache of the cryptographic co-processor. Each function in the set of available functions is configured (e.g., as a programmed HDL function) to read data from three source registers 460, perform a set of calculations, and then output the results to a destination register 465. Data is loaded into the three source registers 460 from a set of three memory locations, as indicated by memory addresses 450.

[0026] The coprocessor may use a word-based addressing system, in which case the memory address 450 may include addresses for w-bit words. The word size w may be selected to match the word size of the external processing unit, or may be selected independently of the word size of the external processing unit. For example, w may include 32 bits or 64 bits. This may help increase bandwidth if the word size of the cryptographic coprocessor is larger than the word size of the external processing unit. This may be desirable in embedded use cases where the external processing unit may be limited to 32 bits, but the cryptographic coprocessor may be configured as having a word length of 64 bits. In general, the external system bus, one or more internal buses used by the coprocessor, and the set of control, source, and / or destination registers may be of different bit widths. This may allow the cryptographic coprocessor to use faster internal memory.

[0027] Memory address 450 may allow three sequences of w bits, corresponding to each of sources A, B, and C, to be loaded into three source registers 460. Similarly, memory address 455 may indicate a location in memory 435 that stores the w-bit output word. As in the previous example, memory 435 may include internal memory of the cryptographic coprocessor, such as internal memory 335 in FIG. 3, or external memory, such as RAM 355 in FIG. 3. Internal memory may be preferred to free up system bus 340 and / or RAM 355 for use by CPU 350 while cryptographic coprocessor 310 is computing the function. In FIG. 4, D=f i A function may be defined as (A, B, C), where f iwhere i is the k number of selectable functions. The function i to be used may be indicated by a bit sequence written to a function identification register in the set of control registers, the bit sequence representing the function number. In a higher level programming language interface, for example for use in computer program code executed by an external processing unit, the function identification values ​​may be set as a list or array of predefined constants.

[0028] In the embodiment 400 of FIG. 4, the control logic 420 may be configured to apply the address generator 425 and the arithmetic calculation engine 430 through a set of iterations. For each iteration, the address generator 425 may recalculate the memory addresses 450 and 455. Thus, for each iteration, the data loaded into the three source registers 460 may change (although it may remain the same for one or more sources, depending on the address generation parameters written to the control registers). The destination memory address 455 may also change for each iteration. Note that depending on the particular path navigation parameters, the generated memory addresses may also be repeated or overlapped, for example to allow for data to be repeated or overwritten as required by a particular operation.

[0029] By performing several iterations, the arithmetic engine 430 may be configured to apply a selected function to a multidimensional array of data associated with each of the three sources (A, B, and C) and output a multidimensional array associated with the destination (D). Such a multidimensional array is shown diagrammatically in FIG. 5A. In the embodiment of FIG. 5A, the cryptographic coprocessor may be considered to operate on a multidimensional array in the form of a matrix 510 (i.e., a two-dimensional array) of data for each of the multiple sources. The multidimensional array may be stored in the memory 435 as a flattened sequence of words that is still represented as a multidimensional data structure by iterating in a series of nested loops. For example, FIG. 5A shows how a two-dimensional block of words may have a width and a height (as measured by some words in a first or X dimension and some words in a second or Y dimension). The size of each of the dimensions of the multi-dimensional array may be set by values ​​stored in a number of control registers, for example, a first control register (CRBL_R_SIZX) may store a bit sequence representing the integer size in words in the first dimension (width) and a second control register (CRBL_R_SIZY) may store a bit sequence representing the integer size in words in the second dimension (height). It is preferred that a set of sources and destinations have multi-dimensional arrays of the same size to reduce the number of control parameters that need to be set and simplify the logic allowing for fast implementation to custom circuits. However, in other implementations, different ones of the sources and destinations may have differently sized arrays. The size of each of the dimensions may be set as an integer value equal to or greater than 1.

[0030] Data may be retrieved from the defined multi-dimensional array by iterating over a sequence of words stored in memory using a set of nested loops, the number of nested loops being equal to the number of dimensions of the multi-dimensional array. For example, two nested loops may be used to iterate over a sequence of words in memory that is treated as a two-dimensional matrix. In one embodiment, an address generator determines source and destination addresses representing a programmable path through each multi-dimensional array of data based on values ​​stored in a set of control registers. The values ​​may indicate, for example, the starting address of the first word in memory, and increment for each dimension. The increments may be positive or negative, allowing for a wide variety of custom paths through the multi-dimensional array. Increments may be applied when iterating over the data. For example, as a row is read, an increment in the X direction may be applied during each iteration, and at the end of the row, an increment in the Y direction may be applied after a set of iterations.

[0031] As an example, consider the sequence "ABCDEFGHIJKLMNOP", where each character represents a word stored in memory. If the size parameters (e.g., CRBL_R_SIZX and CRBL_R_SIZY) are both 4, then the matrix is ​​considered to have 4 rows of length 4. If the increment is 1 in the X direction and 0 in the Y direction, then during an iteration, a row, e.g., A, B, C, D, is read once per word. At the end of the row, the Y increment is applied. If it is set as 0, then nothing happens at the end of the row and the subsequent iteration begins reading the next row, e.g., D, E, F, G, linearly from where the iteration of the previous row ended. This can continue such that the data is read as "ABCDDEFGGHIJJKLM", repeating every fourth word and ignoring the last three words. If there is an increment of 1 in both the X and Y directions (e.g., shown as width and height, respectively, in FIG. 5A), this can allow for a repeat along the row of words (e.g., take the words in the sequence-A, B, C, D across the width) before moving to the next row (e.g., after the first 4 words are read and the row is completed, the Y increment advances by 1 again, so at E the next row-E, F, G, H begins). In this case, "ABCDEFGHIJKLMNOP" is read. By configuring the size and increment, a programmable path through the data may be determined. For example, setting the X increment as 4 and the Y increment as -11 will read the sequence: "AEIMBFJNCGKODHLP", i.e., read along the columns and effectively determine the transpose of the original matrix of data with a width and height of 4 words.

[0032] The set of iterations by the cryptographic coprocessor may form part of an atomic operation from the point of view of the external processing unit. For example, they may be commanded by a single instruction of the external processing unit. The set of iterations may be used to perform a single cryptographic operation on multiple sources, the sources having a multidimensional array of associated data. This operation may be referred to as a "blit" (e.g., of the coprocessor as a "blitter"). The set of iterations may be synchronized to the clock cycle of the external processing unit, for example, a complete set may be executed within one clock cycle of the external processing unit. This may allow for a significant speed increase, as the same cryptographic operation executed on the external processing unit may require multiple fetch, decrypt, and execute cycles for both data and address memory, and may allow the cryptographic coprocessor to make the results available in an accessible memory after a much shorter period of time. In this way, each atomic operation of the cryptographic coprocessor may affect, at most, a set of words that constitute a multidimensional array, i.e., the destination may include a multidimensional array of the same size as the source. In certain embodiments, the clock rate of the cryptographic coprocessor may be different from the clock rate of the external processing unit. In those cases, either the cryptographic coprocessor or the external processing unit may perform the individual steps within a single cycle or more cycles. The number of steps performed may depend on memory bandwidth and, in the case of the external processing unit, on the complexity of the instructions.

[0033] Figure 5B shows an embodiment 520 in which each of the three sources (A, B, C) and destination (D) has independent address generation logic, but each is represented as a two-dimensional matrix as shown in Figure 5A. In this case, each matrix shares the same width and height parameters. Navigation through each matrix is ​​then determined by the starting address, and the X and Y increment parameters (e.g., for both the source and destination).

[0034] The operation in FIG. 5B is similar to that shown in FIG. 4. Block 530 shows a word for each of sources A, B, and C loaded from memory address 535, determined by address generation logic for each source. The address generation logic may form part of address generator 425 in FIG. 4. It may comprise fixed circuitry within an FPGA or ASIC (e.g., as programmed or configured). A function is applied in block 540, and then the output word is stored in destination D, as indicated by destination address 550 calculated by address generation logic for the destination. In FIG. 5B, block 555 shows how the address generation logic for the source and destination can use an outer loop counter that generates "step X" and "step Y" signals based on values ​​for X and Y increment parameters. Thus, for each iteration, new data may be loaded in block 530 based on the X and Y increment parameters for the source, and also stored in different destination addresses in a similar manner. The X and Y step increments may be taken from control registers CRBL_z_INCX and CRBL_z_INCY, where z may be one of A, B, C, and D. The values ​​stored in those control registers may be arbitrary or may be signed to provide a more highly flexible set of programmable paths. If both are set to 1, a linear contiguous block of CRBL_R_SIZX words by CRBL_R_SIZY words is processed. The increments may also be set according to a constant or another control register value. For example, if CRBL_z_INCX=1 and CRBL_z_INCY=-CRBL_R_SIZX+1, the same "row" of CRBL_R_SIZX words is read CRBL_R_SIZY times. This may allow many different cryptographic calculations to be performed with a common hard-programmed function and different programmable paths.For example, a negative Y increment may be set to replicate the reads for one or more of sources A, B, and C in Figure 5A. In the embodiment of Figures 5A and 5B, address generation may be performed by the address generator of the previous embodiment by executing the following pseudocode operations simultaneously with the address generation logic for each of z={A, B, C, D}: Initialize all Z=CRBL_z_ADDR For i=1 to CRBL_R_SIZY do: For j=1 to CRBL_R_SIZX do: Set[D]=F([A],[B],[C]) if(j != CRBL_R_SIZX) then Z=Z+CRBL_z_INCX Else Z=Z+CRBL_z_INCY End For End For Performing address generation for each of the sources and destinations in parallel increases the speed of the coprocessor compared to external processing units. Because lattice encryption is highly based on linear algebra and matrices, the flexibility of programmable paths through the data can allow large-scale matrix multiplications and other large-scale algebraic structures to be computed efficiently. Thus, the functions and operations can relate to one or more of matrix multiplications and additions, polynomial ring multiplications and additions, big integer multiplications and additions, finite field multiplications and additions (among others).

[0035] The coprocessors described herein may also implement some form of shift control in certain implementations. In those implementations, the coprocessor may provide a mechanism for custom shifting of data loaded into the source register of data read from a source address calculated by the address generator of the previous embodiment, for example. The shift control may allow data of a set word size, w bits, to be shifted by a configurable number of bits. This shift may be performed before the function is applied by the arithmetic engine of the previous embodiment, thus providing a further powerful avenue for function customization without requiring changes to the basis functions themselves. It allows the cryptographic coprocessor of the described embodiment to read and combine data in a manner that is not aligned with w-bit word boundaries. In certain cases, a shift may additionally or alternatively be applied to data associated with a destination. For example, it may be desired to shift data in a destination register before storage to a destination memory address to perform rounding of values ​​stored as binary sequences.

[0036] FIG. 6 illustrates an embodiment in which the source and destination registers store 32-bit words, which may be the word size of the external processing unit. To implement the shift control, a plurality of shadow registers corresponding to the plurality of source registers are provided. For example, if the source registers include registers A0, B0, and C0 (e.g., similar to those shown in FIG. 4), a set of shadow registers including registers A1, B1, and C1 may be provided, e.g., the shadow registers are replicas or clones of the source registers. In this case, in response to an instruction to copy data from a plurality of source addresses to a respective one of the plurality of source registers, the coprocessor may be configured to store the previous values ​​of the plurality of source registers in the plurality of shadow registers (i.e., A1=A0, B1=B0, and C1=C0).

[0037] FIG. 6 shows how a custom shift control can be implemented when using the shadow registers described above. FIG. 6 shows a 64-bit concatenation of a new word value in the Zth source register, denoted as Z0 (Z equals one of A, B, or C), with the old word in the Zth shadow register, denoted as Z1. When the shift control is applied, the coprocessor is configured to read a windowed portion of data from the corresponding source and shadow register combination, and a set of control registers indicates shift parameters to control the position of the windowed portion of data. In the example of FIG. 6, the control register CRBL_z_CSRL sets the number of bits by which the start of register Z0 is shifted right. This right shift sets the 32-bit start of the window that is applied to the 64-bit concatenation. This can be understood as shifting the value in source register Z0 left by CRBL_z_CSRL bits and filling the empty value with the bit value shifted in from Z1. The result is then read as the value of the source register instead of Z0, i.e., forms the w-bit input to function (F). For example, there may be three shift control registers CRBL_z_CSRL, one for each source in the embodiment of FIG. 4. In one case, when the sources are provided in the matrix format of FIG. 5A, during the "Y step" (e.g., once every CRBL_R_SIZX step), the shadow registers (A1, B1, C1) may be zeroed to ensure that bit values ​​do not leak from one row to the next. When the CRBL_z_CSRL register is set to zero, the raw value Z0 is used directly, i.e., as described in other embodiments. If the shift value s is an integer value from 1 to (w-1), the source register Z0 is shifted left by s bits and the most significant bit of "s" from Z1 is shifted in (z0<C in C).<s)|z1> >(32-s)).

[0038] By applying the shift control in the above example, the cryptographic coprocessor can apply a custom shift whenever it loads a raw source word (A0, B0, C0) from memory by storing their previous values ​​(A1, B1, C1) and then reading the two shifted combinations. The control register defines how the current word and the previous word are combined to generate the source word used in the function applied by the arithmetic engine.

[0039] 7 shows an example architecture 700 in which a cryptographic co-processor has its own internal memory and is communicatively coupled to a system bus. FIG 7 can be understood as a schematic variation of the architecture shown in FIG 3.

[0040] The embodiment 700 shows a control CPU 710 and an auxiliary processing unit (APU) 720. The auxiliary processing unit 720 may be a cryptographic co-processor as described in the previous embodiment. The control CPU 710 may be the main CPU or a general-purpose CPU for the architecture 700. In FIG. 7, the control CPU 710 and the APU 720 are communicatively coupled via a system bus 730. This system bus 730 may also be used by main RAM, flash ROM, and other peripherals. FIG. 7 shows a memory 740 consisting of a combination of RAM and ROM that can be accessed via the system bus 730. At least the control CPU 710 can access this memory 740, for example, by specifying a memory address and then reading and writing data at that address, and in a particular embodiment, the APU 720 can access the memory 740, although it is generally preferred that the APU 750 uses its own internal RAM 750. This RAM 750 may be accessed by the APU 720 in the same manner that the control CPU 710 accesses the memory 750.

[0041] In FIG. 7, the control CPU 710 controls the APU 720, for example, by writing to a set of memory-mapped control registers as described in the previous embodiment. The memory and control registers may be accessed as memory-mapped resources (e.g., using direct memory access (DMA)) or through a memory management unit (MMU). The control CPU 710 can also access a special-purpose RAM 750 allocated to the APU 720. When initiated by the control CPU 710, the APU 720 operates independently on its data without interaction with the control CPU 710. The control CPU 710 may perform other operations and access memory 740 while the APU 720 operates on its data. Because the APU 720 has its own dedicated RAM interface, the processing performed by the APU 720 does not interrupt or slow down the control CPU 710 and the main system bus 730.

[0042] The cryptographic coprocessors of the embodiments described herein may be configured to operate with most CPUs and instruction set architectures (ISAs) so that they can operate as memory-mapped peripherals. In certain cases, it may be desirable, and possible, to more tightly couple the design with a particular CPU. For example, if the CPU is based on a RISC architecture (e.g., RISC-V), the control registers of the cryptographic coprocessor may be mapped to the CSRs (Control and Status Registers) of the CPU.

[0043] When using its own dedicated memory, the cryptographic coprocessor of the embodiments described herein can exclusively dominate and use all memory accesses for the task, which would necessarily saturate the memory bandwidth of the internal memory, for example. This may not be possible if the cryptographic processor were to access a memory such as 740 that is shared with a CPU such as 710. In a typical two-step or four-step cycle, the cryptographic coprocessor can load three source words and write a single result word (e.g., two steps for a dual-ported RAM or four steps for a single-ported RAM). No additional cycles are required to command loads and interpretations, perform arithmetic calculations, increment memory pointers, and check loop exit conditions. Those functions are performed automatically in hardware. This means that binary operations can be performed fast.

[0044] For example, a cryptographic coprocessor may not have its own program code, since it may lack features such as conditional branching. This means that the cryptographic coprocessor may not be Turing complete and therefore must work closely with the CPU. Efficient use of a cryptographic coprocessor involves the associated CPU preparing the next operation for the coprocessor (e.g., by loading control registers) while the coprocessor is still completing its previous task. Once started, the coprocessor can perform block operations on data stored in RAM. If this RAM is accessed through the same bus used by the main CPU, for example, if this RAM is RAM 740, the coprocessor may slow down the CPU's access to the entire bus while it is operating. This drawback can be avoided by using a dedicated secondary bus and internal RAM 750 as shown in FIG. 7. With this architecture, it may also be easier to secure access to RAM 750.

[0045] In one test implementation, the internal RAM 750 contained 16 kilobytes of working memory. The internal RAM 750 was memory mapped and a base address offset was defined to indicate a starting address within the address space of the control CPU 710. For example, the base address offset - CRBL_BASE_ADDR may be set to say 11000000 (in hexadecimal), and the 16 kilobytes of memory extends up to address 11003FFF (in hexadecimal). The control registers may be memory mapped into the address space in a similar manner. The control address offset - CRBL_CTRL_ADDR may be defined to indicate a starting address of the control registers within the address space of the control CPU 710. The control registers may each be w bits in length (e.g., one word). The control register address space may be before or after the internal memory address space. In the above example, if the control register address space immediately follows the address space allocated to internal RAM 750, the control address offset may be set as 11004000 (i.e., the next address after 11003FFF). In one example, they may include 20 or more control registers. An example set of 32-bit control registers with numbers and hexadecimal offsets from CRBL_CTRL_ADDR is shown in FIG. 8. Some of these control registers have been discussed in the above example. These include a function specifier or identifier - CRBL_R_OPER, a status read - CRBL_R_STAT, a dimension for multi-dimensional arrays - CRBL_R_SIZX and CRBL_R_SIZY (as shown in Figure 5A), a starting address for each of the available sources and destinations - CRBL_z_ADDR and an increment for each of the dimensions - CRBL_z_INCX and CRBL_z_INCY, and a shift control parameter for the source register CRBL_z_CSRL (as described with reference to Figure 6), where z in this case is one of A, B, C, or D as shown.The set of control registers defined in FIG. 8 is provided by way of example only and may vary in the actual implementation, e.g., the number of sources may vary, different dimensions may be defined for each source and destination, and / or different shifts may be implemented. There may also be a level of abstraction applied, e.g., an intermediate array structure may be defined such that one or more of the internal memory and control registers may be accessed using a word index i instead of a set of raw memory addresses and / or offsets. For example, the control CPU 710 may be provided with a programming language interface (e.g., a C Application Programming Interface (API)) that allows accessing the control registers using a crbl_c[n] array (n being the register number) and / or accessing the internal memory using another crbl[i] array (i being the word index). If the control CPU 710 uses byte addressing, then if the APU 720 uses 32-bit words, the APU 720 may know the control CPU address of CRBL_BASE_ADDR+4*i as the word address i (so that 32 bits equals 4 bytes of 8 bits).

[0046] In one case, the internal RAM 750 may include a dual-port type memory that allows two access operations per clock cycle of the APU 720. This may therefore allow four memory addresses to be read within two clock cycles. In this case, there may be three source registers and one destination (i.e., A, B, C, and D) so that data for those registers can be fetched from memory within two clock cycles. The clock cycle of the APU 720 may be at the same frequency as the control CPU 710, or may be different depending on the implementation. Although dual-port RAM is generally more expensive than the single-port RAM that is typically used for RAM in the system memory 740, it can be inexpensively adapted in the proposed embodiment since only a small amount of memory is required to perform the functions of the arithmetic calculation engine. In general, the address generator may be configured to determine an address in the internal dual-port memory, and the multiple source registers may include three internal source registers to allow fast reads from the memory.

[0047] 3 and 7 illustrate the general case where a cryptographic system-on-chip includes a system bus, a central processing unit coupled to the system bus, system memory coupled to the system bus for use by the central processing unit, and a cryptographic coprocessor. The cryptographic coprocessor may be configured as described in any of the previous embodiments (including those described for APU 720), and particular features from one embodiment may be used in combination with one or more features of another embodiment without requiring all features of those embodiments to be provided.

[0048] FIG. 9 illustrates a method 900 for performing cryptographic operations. The method may be applied with any of the coprocessor embodiments previously described or another appropriately configured coprocessor. The coprocessor may also be referred to as an auxiliary processing unit. In certain cases, the method 900 may be programmed into a programmable circuit, for example using HDL or microcode or a low-level programming language. The programmable circuit may include a ROM, FPGA, or programmable ASIC. In certain cases, an ASCI or the like may be configured to perform blocks of the method 900. For example, using a dedicated programmed circuit rather than a general-purpose processing unit reduces costs and speeds up operations.

[0049] The method 900 includes a first block 910 that involves reading values ​​from a set of control registers. These may include control registers 115 in FIG. 1 or control registers 315 in FIG. 3. Values ​​in the set of control registers are written as instructed by a main processing unit communicatively coupled to the coprocessor. For example, CPU 350 or control CPU 710 may write values ​​to addresses in their address space that is memory mapped to the control registers of the coprocessor. The control registers may be similar to the control registers shown in FIG. 8, and the values ​​may include signed or unsigned integer values ​​stored as w-bit words. For example, the size parameters CRBL_R_SIZX and CRBL_R_SIZY may include unsigned (i.e., positive) integers, while the increment parameters CRBL_z_INCX and CRBL_z_INCY may include signed integers (i.e., allowing both positive and negative integer values).

[0050] At block 920, a function to be used by the encryption operation is determined. For example, for a lattice-based encryption operation or a code-based encryption operation, the function may include one or more of Boolean logic and integer arithmetic (e.g., multiplication, addition, and subtraction). A function may be selected from a set of different available functions based on at least one value in a set of control registers, e.g., a positive w-bit integer stored in a function specifier control register CRBL_R_OPER. The function is not a high-level encryption operation such as an encryption or decryption operation, or a symmetric key operation; rather, the function is a mathematical basis function used (e.g., often repeated) within those encryption operations. Thus, the function may correspond to a one-line statement in a higher-level programming language or pseudocode for the encryption operation. For example, the function may involve multiplication of integer values ​​stored as one or more sequences of bits in words in each memory used by the coprocessor, or addition / subtraction of those sequences implemented as binary arithmetic. A function may be described as a discrete function such that it operates on binary sequences, or the integers defined by those binary sequences, as opposed to non-integer representations used to approximate continuous computations.

[0051] At block 930, a set of addresses associated with a respective set of sources and at least one destination is generated. The sources represent inputs to the function. The destinations represent outputs for the function. The sources and destinations may have corresponding registers in the cryptographic coprocessor (e.g., as internal registers or caches for the computations being performed). Those corresponding registers may instead be formed as part of the coprocessor's internal memory. The generated addresses correspond to one or more of the coprocessor's internal memory and the system memory used by the main processing unit, e.g., one of memories 335 or 355 of FIG. 3 or memories 740 or 750 of FIG. 7. As discussed herein, the coprocessor's internal memory is preferred. The addresses are accessible to the main processing unit, e.g., they may form part of the main processing unit's address space. In one case, the internal memory may include memory-mapped resources of the main processing unit. Also, note that although block 930 is shown before block 940, it is only needed for the source, and the determination of the destination address may be performed in parallel with blocks 940 and / or 950 or after blocks 940 and / or 950, as long as it is available for storage of the resulting data in block 960.

[0052] In block 940, data is loaded from a generated address associated with a set of sources. There may be one or more sources. This data will be used as input to the function. This may include a fetch operation, where the address is used to retrieve a word-length sequence of bits from memory and store them in a set of (temporary) source registers from which the data is retrieved to perform the function. In block 950, the function is executed. This may include applying bit operations to the bit sequence stored in the source registers, i.e. the bit sequence read from memory in block 940. The function may be implemented by enacting a set of programmed logic in an FPGA or ASIC. The function may take one or more clock cycles of the coprocessor. The output of the function includes, for example, a word-length or w-bit sequence of bits that can be stored in a (temporary) destination register. Block 950 may include the operations shown in FIG. 4 and / or FIG. 5B.

[0053] In block 960, the output of the function is stored at the generated address associated with the destination. For example, this may involve transferring the value stored in the destination register to one or more of internal or system memories, the location in one of those memories being determined by the generated address.

[0054] At block 970, an indication is provided to the main processing unit that an output is available at the generated address associated with the destination. This may include a passive indication, for example a status read control register such as CRBL_R_STAT in Figure 8 may be set to a predefined value to indicate that the operation is complete (e.g., this may be set to a zero value in the embodiment of Figure 8 to indicate that the coprocessor is no longer busy). In other embodiments, an active indication may be provided, such as an interrupt to the main processing unit.

[0055] In one case, the indication in block 970 is provided only after the set of iterations is completed. The set of iterations may include zero or more iterations (e.g., zero iterations of blocks 930-960, or one or more iterations of those blocks, as indicated by the dashed arrows in FIG. 9). The number of iterations in the set may be defined using a value in a control register.

[0056] In one case, method 900 (particularly blocks 930-960) is repeated to apply a function to a multi-dimensional array of data associated with each of a plurality of sources. This is shown in the example of FIG. 5A and FIG. 5B. In this case, the multi-dimensional array of data associated with the destination may be stored in a plurality of generated addresses associated with the destination, for example, where a different portion of the array is stored after each iteration. As described with respect to FIG. 5A and FIG. 5B, a custom or programmable path through one or more of the plurality of multi-dimensional arrays may be configured via address generation in block 930. For example, the addresses generated in block 930 may be determined based on a starting address (such as CRBL_z_ADDR in FIG. 8, where z={A, B, C, D}) and an increment value for one or more dimensions (such as CRBL_z_INCd in FIG. 8, where z={A, B, C, D} and d={X, Y}). Thus, a complete coprocessor or "blit" operation may be performed on multiple sources, each defined as a multidimensional array, and may provide an output in the form of another multidimensional array, whose values ​​are stored in memory accessible to the main processing unit. An indication may be provided in block 970 when the complete array for the destination is ready for reading.

[0057] In certain embodiments, the coprocessor's operations may be thought of as a pipelined process similar to that of a typical CPU. In those embodiments, certain operations may be performed in parallel and / or optimized to speed up the coprocessor's operations. For example, in a first step in the pipeline, addresses for the source and / or destination are generated, in a second step in the pipeline, a data word is fetched from the source address and optionally shifted (as in FIG. 6), and in a third step, e.g., D=f i (A, B, C) or (D, carry) = f iThe function may be performed as (A, B, C, carry), the latter of which is described in more detail below, and in the fourth step D is written to the destination address. If there is only one source A, the fourth step may be performed, for example, at the same time that the next value of A is loaded so that the previous value is used in the function. If there are three sources A / B / C and a dual-port memory is used, four steps may be performed over two cycles. When the pipeline is optimized and the steps are performed in parallel, in the first step an address for the (t-3)th iteration may be generated, in the second step a data word for the (t-2)th iteration may be fetched, and in the fourth step the function is performed on the stored value for the (t-1)th iteration and the value of D for the tth iteration. The dual-port memory allows two addresses to be read or written in one cycle, so (A, B) may be read in one cycle and C may be read and D may be written in another cycle.

[0058] In general, the method 900 can be understood as one "blit" of the cryptographic coprocessor, with each "blit" running through a region of the multidimensional array (e.g., via a loop shown in dashed lines in FIG. 9). If the multidimensional array is a two-dimensional array such as that shown in FIG. 5A, there may be CRBL_R_SIZX*CRBL_R_SIZY (i.e., width*height) iterations. If the region has been worked out, a new operation may be scheduled, e.g., a new run-through of the method 900. If the operation is a big integer multiplication, the multidimensional array for the source may represent the big integers to be multiplied, e.g., the width and height may each indicate the length of the two numbers to be multiplied. In the case where one or more of the width and height are 1, the operation may represent a column vector operation or a row vector operation.

[0059] The method 900 and the above variants may be executed by a coprocessor. On the side of the main processing unit (or CPU), the method may include a series of blocks before block 910 in FIG. 9. In the first block executed by the main processing unit, the encryption operation to be executed may be determined. This may include instructions to run a known encryption algorithm such as NTRU, Round5, Saber, XMSS, BIKE, Dilithium, or Kyber. The known encryption algorithm may include a post-quantum algorithm, i.e. an encryption algorithm that provides protection against attacks by quantum computers. In general, the encryption algorithm may include one or more of a lattice-based encryption algorithm, a code-based encryption algorithm, an elliptic curve encryption algorithm, and a homogeneous map-based encryption algorithm.

[0060] In the second block, the main processing unit may break down the cryptographic operations into one or more functions. For example, this may include executing compiled code and / or machine code that indicates the functions, and / or may include executing computer program code adapted to use function calls to the coprocessor. For example, a cryptographic algorithm that encrypts, decrypts, or generates a key may have multiple sub-operations that involve a common base Boolean or integer arithmetic function. Those functions may then be identified and assigned to the coprocessor. In certain cases, the cryptographic coprocessor is simply controlled using only writes to a set of control registers, for example, a specific "GO" register is written, which initiates a coprocessor operation (or "blit"). This may be performed using any form of computer program code, including assembly language and low-level coding languages ​​such as C or Rust. The cryptographic coprocessor does not need to be synchronized with the main processing unit, it can simply indicate when it can perform an operation and when a result is available. When the results are available and the coprocessor is no longer busy, a new operation may be initiated by writing back to the control register.In general, the use of a cryptographic coprocessor requires low to moderate changes to the program flow of the higher level cryptographic algorithms.

[0061] Within this method, the main processing unit may iterate through a series of sub-blocks for each identified function to be executed within the encryption algorithm. A first sub-block may include loading values ​​into a set of control registers for the coprocessor as instructed by the main processing unit. There are values ​​that can be read later in block 910 of the method 900. A second sub-block may include loading data into one or more of the internal memory of the coprocessor and the system memory used by the main processing unit as instructed by the main processing unit. For example, the main processing unit may store the data at an identified starting address having an order of magnitude equivalent to the size of any defined multi-dimensional array. The main processing unit may load the data directly into the internal memory of the coprocessor, for example, by accessing it as a memory-mapped resource, and / or the coprocessor may be arranged to retrieve data from the memory used by the main processing unit (e.g., either for direct use or for copying into its own internal memory). For example, in the case of Figure 3 or Figure 7, the coprocessor may directly access external memory (e.g., 355 or 740) to copy chunks to internal memory (e.g., 335 or 750). In a third sub-block, the main processing unit is configured to start the coprocessor by loading a start value into a set of control registers. This may include a Boolean start flag, or may include writing a non-zero function identifier to a function specifier control register (e.g., CRBL_R_OPER in Figure 8).

[0062] Following the sub-blocks described above, the method 900 may be executed. During this time, the main processing unit may wait for an indication that an output is available at the generated address associated with the destination. This may include waiting for an indication as described with reference to block 970, e.g., waiting for a change in a control register value or an interrupt. The main processing unit may perform other operations during the aforementioned wait. For example, this may allow different parts of an encryption algorithm to be effectively parallelized.

[0063] In the implementation of the example of FIG. 8, writing to the CRBL_R_OPER register can start a coprocessor operation, e.g., start method 900, and define a function (e.g., F in FIG. 4 and FIG. 5B) to be performed on multiple sources (e.g., A, B, and C in FIG. 4 and FIG. 5B). In FIG. 8, the w-bit function control word CRBL_R_OPER specifies what type of logic is used to combine the input words of the sources (e.g., A, B, C) to generate the output word D. The architecture is flexible and can support a variable set of functions, depending on the configuration. After ensuring that the appropriate control values ​​have been written to the set of control registers, writing to the CRBL_R_OPER register may be performed. In one case, only the internal variables used by the coprocessor, as indicated by the control register values, are loaded at the beginning of a coprocessor operation ("blit"), so that changing them while the coprocessor is running does not affect that operation. This allows a sequence of coprocessor operations (e.g., "blits", where each "blit" may include method 900) to be executed in immediate succession. For example, an operation for a second function may be prepared when the coprocessor is executing a first function. In certain cases, coprocessor method calls may be defined (e.g., as a C API call) to avoid the need to write directly to the CRBL_R_OPER register. A similar coprocessor method call may be defined for a wait operation where the method call blocks until all running coprocessor operations have finished, for example, by either polling the CRBL_R_STAT status register or by waiting for an interrupt. Both coprocessor method calls are calls executed by the main processing unit.

[0064] The functions applied by the arithmetic engine as described in the embodiments herein may include sub-functions for one or more of code-based encryption and lattice-based encryption, for example, for algorithms as described above. The functions may implement Boolean logic operations, for example, treating source values ​​as bit sequences that can be combined using Boolean logic operations. The functions may also implement integer arithmetic operations, for example, one or more of integer multiplication, integer subtraction, and integer addition, where the integer value is defined by a sequence of bits stored at a defined word address.

[0065] In certain embodiments, the cryptographic coprocessor described in the embodiments herein may be configured to evaluate multiple functions and store respective outputs at respective multiple destination addresses. For example, the cryptographic coprocessor may include multiple arithmetic engines and / or an arithmetic engine capable of evaluating multiple functions at once. In one case, multiple functions may be evaluated in parallel and outputs may be stored at corresponding destination addresses. The functions evaluated simultaneously may include different functions. They may be set based on a common function set. The functions may be selectable via respective function identifiers in a set of control registers. In one case, each function may operate on the same set of sources but produce different destination results. In this case, the control logic of the cryptographic coprocessor may be configured to select one of the destinations. This selection may be performed conditionally, for example, based on a value stored at the destination. In another similar variation, there may be multiple cryptographic coprocessors sharing a common memory, similar to, for example, internal memory 335 in FIG. 3.

[0066] FIG. 10 shows how a truth table for an example Boolean logic operation may be defined. As explained above, this may be set using the value stored in the CRBL_R_OPER register of FIG. 8. For example, when 32-bit words are used and the value of CRBL_R_OPER is a value of the form 000000xx (e.g., the most significant 24 bits are zero), the 8-bit value xx may define a truth table for any 3-input Boolean function where the Boolean function is applied to bits of the source (e.g., A, B, and C). Each of those least significant 8 bits thus defines how an output for the destination (D) will be generated for a given combination of input bits (e.g., as shown by the words A, B, C).

[0067] For example, if the 8 bits are viewed as a set of 1-bit variables "hgfedcba," the most significant bit ("h") is "operation bit 7" in FIG. 10, and the least significant bit ("a") is "operation bit 0" in FIG. 10. Setting the values ​​of each of the 1-bit variables then indicates the output of different 1-bit combinations shown in the last three rows of the table in FIG. 10. For example, bit value "a" indicates the result of combining three 0 bits in each of the sources (e.g., 0 or 1), bit value "d" indicates the result of combining a 0 in the A source with a 1 in the B and C sources, and bit value "h" indicates the result of combining three 1 bits in each of the sources. Thus, each different 8-bit sequence defines a different truth table. As an example, if one bit from each of the sources (A, B, C) is equal to (1, 0, 1), then the function identifier 0xCC (in hex) means that the sequence "hgfedcba" is equal to 11001100, so that "operation bit 5" ("f") is equal to 0 and the output of the combination (i.e., D) is 0. By comparison, if the function identifier is 0x80 (in hex), this means that the sequence "hgfedcba" is equal to 1000000, i.e., a logical AND operation on all three sources. Bit-by-bit comparisons may be performed in parallel for each bit in the sequence in the sources, e.g., if the register is 32-bit, then 32-bit comparisons are performed in parallel. If there are n sources, then 2 bits in the function identifier are equal to 11001100, so that "operation bit 5" ("f") is equal to 0 and the output of the combination (i.e., D) is 0. n The bits dictate a truth table, so the cryptographic coprocessor can implement multiple custom binary logic operations.

[0068] A constant may be assigned to a particular value of the function specifier, for example a mask operation that fills the destination with ones may have a function specifier value of 000000FF, which may be defined as a C constant (CRBL_OP_MASK) for the program on the main processing unit. The constant CRBL_OP_MASK may be used to ensure that the high order bits are zero. All zeros (i.e., 00000000) may be a function that ignores the input and simply writes zeros to the destination. A value of 000000F0 (e.g., set as the constant CRBL_OP_ASRC) may simply duplicate the value stored in source register A to destination D, and CRBL_R_OPER set to CRBL_OP_ASRC & CRBL_OP_MASK (i.e., the value and mask mentioned above) may result in the logical inverse of the same source register being written to destination D. Different combinations of the defined constants may be used to indicate different Boolean operations. For example, if CRBL_OP_BSRC is set to 0x000000CC (duplicate the value in source register B to destination D) and CRBL_OP_CSRC is set to 0x000000AA (duplicate the value in source register C to destination D), then an expression such as (CRBL_OP_ASRC&CRBL_OP_BSRC)^CRBL_OP_CSRC evaluates to 0x6A, leading to a Boolean operation of (A AND B) XOR C. Boolean operations can be useful for a variety of tasks. They can be particularly useful for (bit-sliced) implementations of symmetric encryption algorithms.

[0069] Another example of a function that can form part of the set of functions are the so-called "row arithmetic" primitives. Row arithmetic primitives allow the coprocessor to rapidly add and subtract integer vectors from one another. Different functions can interpret bit sequences stored in a set of input source registers (e.g. A, B, and C) in different ways. One function can compute D=A+BC, with source registers A, B, C interpreted as a packed array of four 8-bit integers. Another function can compute the same sequence of additions and subtractions, i.e. D=A+BC, but interpret source registers A, B, C as packed arrays of two 16-bit integers. For example, if w=32 and 8-bit arithmetic is used, there are effectively four parallel, independent 8-bit arithmetic operations performed, e.g. the second byte of destination D depends on the second byte of sources A, B, C, and either result can be interpreted as modulo 256.

[0070] In particular embodiments, the functions applied by the arithmetic engine are stateless. However, to allow for long integer arithmetic (e.g., long meaning that overflow or underflow may occur), an additional "carry" register may be used by the arithmetic engine to store the carry for the arithmetic calculation. This is expressed as (D, carry)=f i(A, B, C, carry). For example, a function may be defined that has the same sum D=A+BC, but where the source register is interpreted as a full-length w-bit integer. In this case, an additional carry variable may need to be set, which may be accessible from the carry register. The carry register may also store a negative value indicating a "borrow". When iterating through a multi-dimensional array (when performing a step in the Y dimension), the carry register may be reset at the beginning of each row. Each of those row operation primitives may have a different function specifier (i.e., identifier) ​​value. The carry may not be available for direct reading by an external processing unit. In one implementation, the carry register may be cleared at the beginning of each operation (e.g., each execution of method 900) and / or at the end of each row (when doing the Y increment as previously described).

[0071] Another function may be integer multiplication. As with the row operation primitives, integer multiplication may be performed with different interpretations of source register bit sequences using different function specifier values. A multiplication function for three sources (A, B, and C) may include the combinatorial function D=A+B*C. In one case, integers of any length (e.g., large) may be multiplied in a single operation (single execution of method 900) on the coprocessor. This may use the carry. In a particular integer multiplication, a 2w-bit product may be calculated, which may be divided between the w bits in the destination register and the w bits in the carry register. An equivalent description of the combinatorial function D=A+B*C of an arbitrary length multiplication function in the C programming language is: carry+=((uint64_t)a_data)+((uint64_t)b_data)*((uint64_t)c_data); d_data = (uint32_t) carry; carry>>=32; may be also possible.

[0072] An example of how the above big integer multiplication can be configured is now described. This example also shows how the coprocessor can be configured to use multi-dimensional arrays. A little-endian big integer representation is assumed (however, other representations may be configured via the function definition). In this case, an integer of "m-1" words defined as source B is multiplied by an integer of n words defined as source C. Source B is defined starting at CRBL_B_ADDR with an additional high-order word set to zero (i.e., it is actually a bit sequence of m words), and source C is defined starting at CRBL_C_ADDR. First, the destination array of (n+m-1) words is cleared and both source A (e.g., as defined via CRBL_A_ADDR) and destination D (e.g., as defined via CRBL_D_ADDR) are configured to point to it. The full product B*C can then be calculated with a single operation of the coprocessor (e.g., one iteration of method 900). The configuration may be prepared using the following C code: crbl_c[CRBL_A_INCX]=1; / / A:(X)Advance by 1. crbl_c[CRBL_A_INCY]=2-m; / / A:(Y)Rewind back, advance by one. crbl_c[CRBL_A_CSRL] = 0; crbl_c[CRBL_B_INCX]=1; / / B:(X)Advance by 1. crbl_c[CRBL_B_INCY]=1-m; / / B:(Y)Rewind all the way back. crbl_c[CRBL_B_CSRL] = 0; crbl_c[CRBL_C_INCX]=0; / / C:(X)Same value entire row. crbl_c[CRBL_C_INCY]=1; / / C:(Y)advance by 1 crbl_c[CRBL_C_CSRL]=0; crbl_c[CRBL_D_INCX]=1; / / D:(X)Same as A, advance by 1. crbl_c[CRBL_D_INCY]=2-m; / / D:(Y)Rewind back, advance by one. crbl_c[CRBL_R_SIZX]=m; / / Width(B size+1 zero word). crbl_c[CRBL_R_SIZY]=h; / / Height(C size). crbl_go(CRBL_OP_M32A); / / Start the multiplication operation. crbl_wait(); / / (Wait for it to finish.)

[0073] In the above operation, the destination is initially set to 0 and the source register A is used to reload the intermediate value before the final product is prepared. As a (hypothetical) example using decimal values, imagine that it is needed to multiply the value 123*456 and the word size is a single decimal digit. In this case B=123 and C=456. For the first set of iterations: A=0, B*C=3*6=18, D=8, carry out=1; A=0, B*C=2*6=12+1=13, D=3, carry out=1; and A=0: B*C=1*6=6+1=7: D=0, carry out=0. Those iterations represent the first row and D=00738. Now for the second set of iterations representing the second row, A=D and A and B are rewound. For the second set of iterations, A, C, D are stepped through, effectively stepping A, D through the middle three digits. Thus the second set of iterations proceeds as follows: A=3, B*C=3*5=15+3=18, D=8, carry out=1; A=7, B*C=2*5=10+7+1=18, D=8, carry out=1; and A=0, B*C=1*5=5+1=6, D=6, carry out=0. Now the second row is completed and D=06888. For the third set of iterations, the top three digits of A and D are stepped through: A=8, B*C=3*4=12+8=10, D=0, carry out=1; A=6, B*C=2*4=8+6+1=16, D=6, carry out=1; and A=0, B*C=1*4=4+1=5, D=4, carry out=0. After this line, D=56088=123*456 and the final result is output after a single operation or "blit". Of course, in reality, integers would be represented as binary values ​​rather than decimal integers, but the steps are similar.

[0074] Certain embodiments described herein provide methods and systems for supporting the main processing unit with cryptographic operations. The methods and systems allow cryptographic operations to be performed with less processor overhead and with less complexity. As fewer cycles of main processing unit operations are required, power consumption can also be reduced and the coprocessor can be implemented as a low-power FPGA or ASIC. This provides advantages that may not be possible with vector or single instruction multiple data (SIMD) processors by comparison. For example, SIMD is implemented primarily as a feature of the main processing unit or external processing unit rather than with a separate coprocessor, and the cryptographic coprocessor may not have machine instructions or "instruction flow" as SIMD architectures do. Also, in architectures that support SIMD register access, vectors or arrays are treated as part of the CPU's register file, which means that the amount of data that can be stored without loading and storing to the main (i.e., external) memory is greatly limited, as access to the system bus and main memory is via the main processing unit or external processing unit.

[0075] The coprocessor is adapted to perform arithmetic calculations such as a variety of common cryptographic basis functions, e.g., complex bit manipulation operations consisting of word addition or subtraction or shifting, indirect addressing, and evaluation of multi-input Boolean functions. Those common cryptographic basis functions may be designed to support one or more known post-quantum cryptographic algorithms. The coprocessor may be used to help implement post-quantum (i.e., quantum-safe) cryptography for a wide range of devices, from servers to smart cards. The coprocessor is specifically designed to accelerate cryptographic operations such as large-scale linear algebra and big integer arithmetic calculations. This differs from floating-point coprocessors by comparison, which are designed to operate with bit sequences that define the exponent and mantissa, but are not suitable for performing common cryptographic basis functions. The basic design of the coprocessor incorporating the aspects described in this embodiment may be flexibly configured to address the challenges of implementation aspects of different types of cryptographic algorithms (which can use the same basis functions in different orders and combinations), including helping to immediately support algorithms that are developed later. For example, if a smart card is only needed to implement one encryption algorithm that simply requires row arithmetic primitives, and then a smaller sized coprocessor can be provided, the set of functions that can be performed by the coprocessor may be configured according to the needs of the target system.

[0076] Certain embodiments described herein provide an encryption architecture and a method of operating such an architecture that efficiently interfaces specialized encryption processing units with larger processing units. Certain embodiments described herein provide an encryption method that can be suitable for implementation in low resource microcontrollers and embedded devices as well as implementation for high speed secure data processing. The described encryption architecture is agnostic to the type of processing unit used, with options for different control procedures available through a set of control registers. The encryption architecture may be implemented using memory mapping and / or other approaches, thus providing easy and transparent data access to different types of processing units. Certain embodiments described herein may be used to enable efficient hardware and / or software implementation of higher level encryption algorithms that use smaller base encryption functions as "building blocks". The encryption coprocessor may execute fast encryption base functions instead of a processor or microprocessor, which itself provides benefits for both low power embedded devices and high throughput server devices.

[0077] Although particular embodiments refer to accessing data in particular registers and reading and / or writing data to such registers, it will be understood that in practice intermediate data storage devices and / or data structures may be used in particular implementations, and references to "data therein" may also apply, for example, to data "derived from" resulting from one or more intermediate steps in addition to those described. References to a set of registers may indicate references to one or more registers. Embodiments that characterize a main processing unit, an external processing unit, or a central processing unit may also feature multiple such units of the same or different types. For example, a computing system in which a cryptographic coprocessor is implemented may include a heterogeneous system having multiple CPUs of different types, for example, where the CPUs share a common system bus. Additionally, although "control" of the coprocessor has been described with respect to an external processing unit, other devices such as disk drives and network interfaces may perform DMA (direct memory access) transfers to accessible coprocessor memory regions. It will also be understood that references to circuitry associated with a particular component may instead be implemented as functionality within the component, whether through, for example, executed firmware code and / or dedicated hardware circuitry. A "circuitry" as described herein may be implemented in hardware, for example, using digital logic gates or programmable gates in an FPGA and / or as computer program code that is loaded from a memory and executed by a processor, such as a microprocessor. Certain system components and methods described herein may be implemented by computer program code, such as firmware or instruction sets, that may be stored in a non-transitory storage medium, such as a read-only updatable firmware memory.

[0078] The above embodiments are to be understood as examples. Further embodiments are envisioned. For example, the specific values ​​discussed herein are based on test embodiments and may vary depending on the implementation (e.g., depending on the use and type of microcontroller, security requirements, and other factors). Although specific components of each embodiment have been described separately, it will be understood that functionality described with reference to one embodiment may be implemented in another embodiment as appropriate, and that specific components may be omitted depending on the implementation. It will be understood that any feature described in connection with any one embodiment may be used alone or in combination with other features described, and may also be used in combination with one or more other features of any of the embodiments, or in any other combination of any of the embodiments. For example, features described with respect to system components may also be adapted to be performed as part of the described method. Moreover, equivalents and modifications not described above may also be employed without departing from the scope of the invention, as defined in the appended claims. [Explanation of symbols]

[0079] 110 Coprocessor 115 Control Register 120 Control Logic 125 Arithmetic Calculation Engine 130 Address Generator 315 Control Register 320 Control Logic 325 Address Generator 330 Arithmetic Unit 335 Internal Memory 365 I / O Interface 375 other modules 420 Control Logic 425 Address Generator 435 Memory

Claims

1. A co-processor for cryptographic operations, the co-processor being communicatively coupled to an external processing unit; a set of control registers writable by said external processing unit; an arithmetic engine for performing a function on binary data stored in a set of source registers and storing an output of the function in at least one destination register, the function being applied to each set of bit sequences stored in the set of source registers that represent integer values, the function being selected from a set of functions including one or more of Boolean logic and integer arithmetic; an address generator for generating a set of source addresses used to load binary data from a memory into said set of source registers and at least one destination address used to store binary data from said at least one destination register into a memory; control logic for controlling the operation of the arithmetic engine and the address generator based on values ​​stored in the set of control registers, the control logic being configured to select the function from the set of functions based on at least one value of the set of control registers; The coprocessor comprising:

2. 2. The coprocessor of claim 1, wherein at least the set of control registers are accessible by the external processing unit as a memory-mapped resource.

3. an internal memory accessible to said external processing unit; the set of source addresses and the at least one destination address comprise addresses within the internal memory; the internal memory is accessible by the external processing unit as a memory mapped resource; A coprocessor according to claim 1 or claim 2.

4. an external memory interface communicatively coupling the co-processor to an external memory, the external memory being a memory for the external processing unit; the set of source addresses and the at least one destination address include addresses in the external memory. A coprocessor according to claim 1 or claim 2.

5. the control logic is applied to the arithmetic engine and the address generator through a set of iterations to perform operations on binary data associated with a plurality of sources and output binary data associated with a destination; Through the set of iterations, the address generator generates a set of source addresses associated with a matrix of data for each source and a set of destination addresses associated with a matrix of data for the destination; Through the set of iterations, an arithmetic calculation unit is applied to the matrices of data for the multiple sources to output the matrices of data for destinations. A coprocessor according to any one of claims 1 to 4.

6. 6. The coprocessor of claim 5, wherein the address generator generates source and destination addresses representing programmable paths through matrices of each of the data based on values ​​stored in the set of control registers.

7. The values ​​stored in the set of control registers are a starting address for the plurality of sources; a positive or negative increment in each of two dimensions of the matrix of data, the increments being applied during an iteration of the arithmetic calculation engine. The coprocessor of claim 6.

8. A coprocessor as claimed in any preceding claim, wherein the address generator is configured to generate addresses in an internal dual port memory, and the set of source registers comprises three internal source registers.

9. a set of shadow registers corresponding to the set of source registers; in response to an instruction to copy data from the set of source addresses to a respective one of the set of source registers, the coprocessor is configured to store a previous value in the set of source registers of the set of shadow registers; A coprocessor according to any preceding claim.

10. 10. The coprocessor of claim 9, wherein for a given source, the coprocessor is configured to read a windowed portion of data from a combination of the corresponding source register and shadow register, and the set of control registers indicates shift parameters for controlling a position of the windowed portion of data.

11. A coprocessor as claimed in any preceding claim, wherein the integer arithmetic calculations include one or more of integer multiplication, integer subtraction and integer addition.

12. A coprocessor according to any preceding claim, wherein the set of functions includes sub-functions for one or more of code-based encryption and lattice-based encryption.

13. A coprocessor as claimed in any preceding claim, wherein the coprocessor is initiated via the external processing unit writing a function identifier to the set of control registers, the function identifier being used to select the function from the set of functions.

14. A coprocessor as claimed in any preceding claim, wherein the coprocessor is arranged to evaluate a plurality of functions and store respective outputs in a respective plurality of destination addresses.

15. 1. A cryptographic system-on-chip, comprising: A system bus; a central processing unit coupled to the system bus; a system memory coupled to the system bus for use by the central processing unit; a coprocessor, the coprocessor comprising: a set of control registers writable by said central processing unit; The internal memory and a set of internal encryption registers including a set of source registers and at least one destination register; an arithmetic engine for performing a function on binary data stored in the set of internal cryptographic registers, the function being applied to a set of respective bit sequences stored in the set of source registers that represent integer values, the function being selected from a set of functions including one or more of Boolean logic and integer arithmetic; an address generator that generates a set of source addresses used to load binary data from one or more of the internal memory and the system memory into the set of source registers, and at least one destination address used to store binary data from the at least one destination register into one or more of the internal memory and the system memory; control logic for controlling the operation of the arithmetic engine and the address generator by the central processing unit based on values ​​stored in the set of control registers, the control logic being configured to select the function from the set of functions based on at least one value of the set of control registers; The encryption system-on-chip.

16. 16. The cryptographic system-on-chip of claim 15, wherein the set of control registers and the internal memory of the coprocessor are mapped into a secure address space of the central processing unit.

17. 17. A cryptographic system-on-chip according to claim 15 or claim 16, wherein the co-processor is secured within the cryptographic system-on-chip using one or more of security fuses and side-channel attack countermeasures.

18. 1. A method of performing a cryptographic operation, comprising: reading, by an auxiliary processing unit, values ​​from a set of control registers for the auxiliary processing unit, the values ​​being written as instructed by a main processing unit communicatively coupled to the auxiliary processing unit; determining a function to be executed by the auxiliary processing unit to be used by the cryptographic operation, the function being selected from a set of functions including one or more of Boolean logic and integer arithmetic based on a value of at least one of the set of control registers; generating a set of addresses associated with each set of sources and at least one destination, the addresses corresponding to one or more of an internal memory of the auxiliary processing unit and a system memory used by the main processing unit, the addresses being accessible to the main processing unit; loading data from generated addresses associated with the set of sources; applying the determined function to the data; and storing an output of the function at a generated address associated with the at least one destination; indicating to the main processing unit that the output is available at the generated address associated with the destination; The method comprising:

19. At least a portion of the method is repeated to apply the function to a multi-dimensional array of data associated with each of a plurality of sources forming the set of sources; a multi-dimensional array of data associated with the destination is stored at a plurality of generated addresses associated with the destination; a custom path through one or more of the plurality of multi-dimensional arrays is constructed using a starting address and an increment value for one or more dimensions stored in the set of control registers; 20. The method of claim 18.

20. Prior to the reading step, determining a cryptographic operation to be performed by the main processing unit; decomposing said cryptographic operations into one or more functions; For a function within the one or more functions: loading values ​​into a set of control registers for the auxiliary processing unit as instructed by the main processing unit; loading data into one or more of the internal memory of the auxiliary processing unit and the system memory used by the main processing unit as instructed by the main processing unit; starting said auxiliary processing unit by loading a starting value into said set of control registers; awaiting an indication that output is available at the destination; the main processing unit is free to perform other operations during the wait; 20. The method of claim 18 or 19.

Images