U.S. patent application number 13/628554 was filed with the patent office on 2013-01-24 for architecture and implementation method of programmable arithmetic controller for cryptographic applications.
This patent application is currently assigned to LSI CORPORATION. The applicant listed for this patent is LSI Corporation. Invention is credited to Anatoli Bolotov, Alexei Galatenko, Mikhail Grinchuk, Lav Ivanovic.
Application Number | 20130024668 13/628554 |
Document ID | / |
Family ID | 42355093 |
Filed Date | 2013-01-24 |
United States Patent
Application |
20130024668 |
Kind Code |
A1 |
Bolotov; Anatoli ; et
al. |
January 24, 2013 |
ARCHITECTURE AND IMPLEMENTATION METHOD OF PROGRAMMABLE ARITHMETIC
CONTROLLER FOR CRYPTOGRAPHIC APPLICATIONS
Abstract
An architecture includes a controller. The controller is
configured to receive a microprogram. The microprogram is
configured for performing at least one of hierarchical or a
sequence of polynomial computations. The architecture also includes
an arithmetic logic unit (ALU) communicably coupled to the
controller. The ALU is controlled by the controller. Additionally,
the microprogram is compiled prior to execution by the controller,
the microprogram is compiled into a plurality of binary tables, and
the microprogram is programmed in a command language in which each
command includes a first portion for indicating at least one of a
command or data transferred to the ALU, and a second portion for
including a control command to the controller. The architecture and
implementation of the programmable controller may be for
cryptographic applications, including those related to public key
cryptography.
Inventors: |
Bolotov; Anatoli; (San Jose,
CA) ; Grinchuk; Mikhail; (San Jose, CA) ;
Ivanovic; Lav; (Sunnyvale, CA) ; Galatenko;
Alexei; (Moscow, RU) |
|
Applicant: |
Name |
City |
State |
Country |
Type |
LSI Corporation; |
Milpitas |
CA |
US |
|
|
Assignee: |
LSI CORPORATION
Milpitas
CA
|
Family ID: |
42355093 |
Appl. No.: |
13/628554 |
Filed: |
September 27, 2012 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
12321643 |
Jan 23, 2009 |
8302083 |
|
|
13628554 |
|
|
|
|
Current U.S.
Class: |
712/221 ;
712/E9.017 |
Current CPC
Class: |
G06F 9/3001 20130101;
G06F 21/72 20130101 |
Class at
Publication: |
712/221 ;
712/E09.017 |
International
Class: |
G06F 9/302 20060101
G06F009/302 |
Claims
1. An architecture comprising: a controller, the controller
configured to receive a microprogram, the microprogram configured
for performing at least one of hierarchical or a sequence of
polynomial computations; and an arithmetic logic unit (ALU)
communicably coupled to the controller, the ALU controlled by the
controller, wherein the microprogram is compiled prior to execution
by the controller, the microprogram is compiled into a plurality of
binary tables, and the microprogram is programmed in a command
language in which each command includes a first portion for
indicating at least one of a command or data transferred to the
ALU, and a second portion for including a control command to the
controller.
2. The architecture of claim 1, wherein the plurality of binary
tables includes four binary tables.
3. The architecture of claim 1, wherein the plurality of binary
tables includes a PROGRAM ROM binary table, a LABEL ROM binary
table, a FUNCTION ROM binary table, and an F_id DECODER binary
table.
4. The architecture of claim 3, wherein the PROGRAM ROM binary
table includes binary code of the microprogram to be executed
during runtime, the LABEL ROM binary table includes addresses of
commands labeled in the microprogram, the FUNCTION ROM binary table
includes addresses of functions and subfunctions as entry points to
be called during execution, and the F_id DECODER includes indices
of functions accessible for external control for decoding.
5. The architecture of claim 3, wherein the microprogram includes
indices for the LABEL ROM binary table and the FUNCTION ROM binary
table, the indices requiring less memory than full addresses of
commands.
6. The architecture of claim 1, further including a hierarchical
function library, the hierarchical function library storing
separate blocks of subprograms and subfunctions in at least four
levels of subprograms and subfunctions.
7. The architecture of claim 6, wherein the at least four levels
include a top level for including protocols, an application level
for including relatively complex operational functionality, an
arithmetic level for including operational functionality, and a
ground level for including initial ALU operations.
8. The architecture of claim 7, wherein only the ground level
requires direct hardware support for implementation.
9. A method comprising: programming a microprogram in a command
language in which each microprogram command includes a first
portion for indicating at least one of a command or data
transferred to an arithmetic logic unit (ALU), and a second portion
for including a control command to a controller; compiling the
microprogram into a plurality of binary tables, the microprogram
configured for performing at least one of hierarchical or a
sequence of polynomial computations; executing the microprogram by
a controller; configuring at least one of the plurality of binary
tables for including the code of the microprogram; and configuring
at least one of the plurality of binary tables for storing at least
one address of a command labeled in the microprogram.
10. The method of claim 9, further including configuring at least
one of the plurality of binary tables for storing addresses of at
least one of a function or a subfunction as an entry point for
calling during execution of the microprogram.
11. The method of claim 9, further including configuring at least
one of the plurality of binary tables for decoding indices of
functions accessible for external control.
12. The method of claim 9, further including performing at least
one of editing the microprogram or generating binary tables, during
which a controller netlist remains unchanged.
13. The method of claim 9, wherein compiling the microprogram into
a plurality of binary tables includes compiling the microprogram
into a PROGRAM ROM binary table, a LABEL ROM binary table, a
FUNCTION ROM binary table, and an F_id DECODER binary table.
14. The method of claim 9, wherein compiling the microprogram into
a plurality of binary tables includes compiling the microprogram
from a hierarchical function library.
15. The method of claim 14, further including storing separate
blocks of subprograms and subfunctions in at least four levels of
subprograms and subfunctions, the at least four levels include a
top level for including protocols, an application level for
including relatively complex operational functionality, an
arithmetic level for including operational functionality, and a
ground level for including initial ALU operations.
16. The method of claim 15, further comprising providing hardware
support for only the ground level.
17. A system comprising: a controller, the controller configured to
receive a microprogram, the microprogram configured for performing
at least one of hierarchical or a sequence of polynomial
computations; an arithmetic logic unit (ALU) communicably coupled
to the controller, the ALU controlled by the controller; and a
command register communicably coupled to the controller, the
command register controlled by the controller and configured for
storing at least one of input data, output data, or internal
registers, wherein the microprogram is compiled prior to execution
by the controller, the microprogram is compiled into four binary
tables, and the microprogram is programmed in a command language in
which each command includes a first portion for indicating at least
one of a command or data transferred to the ALU, and a second
portion for including a control command to the controller.
18. The system of claim 17, wherein the four binary tables include
a PROGRAM ROM binary table, a LABEL ROM binary table, a FUNCTION
ROM binary table, and an F_id DECODER binary table.
19. The system of claim 18, wherein the PROGRAM ROM binary table
includes binary code of the microprogram to be executed during
runtime, the LABEL ROM binary table includes addresses of commands
labeled in the microprogram, the FUNCTION ROM binary table includes
addresses of functions and subfunctions as entry points to be
called during execution, and the F_id DECODER includes indices of
functions accessible for external control for decoding.
20. The system of claim 18, wherein the microprogram includes
indices for the LABEL ROM binary table and the FUNCTION ROM binary
table, the indices requiring less memory than full addresses of
commands.
Description
CROSS REFERENCE TO RELATED APPLICATIONS
[0001] The present invention claims the benefit under 35 U.S.C.
.sctn.120 to U.S. patent application Ser. No. 12/321,643, filed
Jan. 23, 2009. Said U.S. patent application Ser. No. 12/321,643 is
hereby incorporated by reference in its entirety.
FIELD OF THE INVENTION
[0002] The present invention generally relates to the field of data
processing, and more particularly to an architecture and
implementation method for a programmable arithmetic controller.
BACKGROUND OF THE INVENTION
[0003] Cryptographic applications, including cryptosystems and
cryptographic protocols, typically require various hierarchical
arithmetical/polynomial computations to implement functional
benefits. Such cryptographic applications may include functionality
such as multiparty key exchange schemes, identity-based
encryption/decryption, and other security and e-commerce-based
functions. Computer systems are often used to implement the
relatively complex protocols and computations.
SUMMARY OF THE INVENTION
[0004] An architecture includes a controller. The controller is
configured to receive a microprogram. The microprogram is
configured for performing at least one of hierarchical or a
sequence of polynomial computations. The architecture also includes
an arithmetic logic unit (ALU) communicably coupled to the
controller. The ALU is controlled by the controller. Additionally,
the microprogram is compiled prior to execution by the controller,
the microprogram is compiled into a plurality of binary tables, and
the microprogram is programmed in a command language in which each
command includes a first portion for indicating at least one of a
command or data transferred to the ALU, and a second portion for
including a control command to the controller.
[0005] A method includes programming a microprogram in a command
language in which each microprogram command includes a first
portion for indicating at least one of a command or data
transferred to an arithmetic logic unit (ALU), and a second portion
for including a control command to a controller. The method also
includes compiling the microprogram into a plurality of binary
tables. The microprogram is configured for performing at least one
of hierarchical or a sequence of polynomial computations. The
method further includes executing the microprogram by a controller,
configuring at least one of the plurality of binary tables for
including the code of the microprogram, and configuring at least
one of the plurality of binary tables for storing at least one
address of a command labeled in the microprogram.
[0006] A system includes a controller. The controller is configured
to receive a microprogram. The microprogram is configured for
performing at least one of hierarchical or a sequence of polynomial
computations. The system also includes an arithmetic logic unit
(ALU) communicably coupled to the controller. The ALU is controlled
by the controller. The system further includes a command register
communicably coupled to the controller, the command register
controlled by the controller and configured for storing at least
one of input data, output data, or internal registers.
Additionally, the microprogram is compiled prior to execution by
the controller, the microprogram is compiled into four binary
tables, and the microprogram is programmed in a command language in
which each command includes a first portion for indicating at least
one of a command or data transferred to the ALU, and a second
portion for including a control command to the controller.
[0007] It is to be understood that both the foregoing general
description and the following detailed description are exemplary
and explanatory only and are not necessarily restrictive of the
invention as claimed. The accompanying drawings, which are
incorporated in and constitute a part of the specification,
illustrate an embodiment of the invention and together with the
general description, serve to explain the principles of the
invention.
BRIEF DESCRIPTION OF THE DRAWINGS
[0008] The numerous advantages of the present invention may be
better understood by those skilled in the art by reference to the
accompanying figures in which:
[0009] FIG. 1 is a block diagram of an arithmetic module
architecture including a microcontroller;
[0010] FIG. 2 is a block diagram of the arithmetic module
architecture of FIG. 1, including a command language
compilation;
[0011] FIG. 3 is a block diagram of the microcontroller of FIG.
1;
[0012] FIG. 4 is a portion of a microprogram for executing by the
microcontroller; and
[0013] FIG. 5 is a flow chart illustrating a method for
implementing a programmable arithmetic controller.
DETAILED DESCRIPTION OF THE INVENTION
[0014] Reference will now be made in detail to the presently
preferred embodiments of the invention, examples of which are
illustrated in the accompanying drawings.
[0015] Referring generally to FIGS. 1-2, a block diagram of an
arithmetic module architecture 100 including a microcontroller 102
is shown. The microcontroller 102 may be a built-in programmable
arithmetic controller, which may run and control an
application-specific arithmetic logic unit (ALU) 104 and a command
register 106. For instance, the ALU 104 may be a component used for
arithmetic, comparative, and logic functions, and the command
register 106 may be configured for storing input/output data and
internal registers. Furthermore, the microcontroller 102 (including
the architecture and the implementation thereof) may be utilized
for cryptographic applications, including those applications
related to the public key cryptography. For instance, the
microcontroller 102 may be utilized for cryptographic protocols
typically having hierarchical and complex computational structure,
such as those involving relatively large integers and polynomials
of high degree and with complex arithmetic operations.
[0016] The microcontroller 102 may be configured to execute a
microprogram 108, which may be compiled prior to execution by the
microcontroller 102. The microprogram 108 may consist of separate
blocks of subprograms/subfunctions stored in a hierarchical
function library 110 (as shown in FIG. 2) that may be called by an
external control module or an external microprocessor. In the
embodiment shown in FIG. 2, the hierarchical function library 110
includes 4 levels of subprograms/subfunctions: (1) a top level
110a, (2) an application level 110b, (3) an arithmetic level 110c,
and (4) a ground level 110d. The top level 110a may include
protocol functionality for such functions as signatures, key
exchange, encryption, and the like. The application level 110b may
include coding for relatively complex operations, such as those
utilized in cryptosystem and cryptographic protocols, including
exponentiation, inversion, point addition, doubling, and the like.
The arithmetic level 110c may include operation functionally,
including multiplication, addition, subtraction, comparison, module
reduction, and the like. The ground level 110d may include ALU
proto-operations such as register transfer, basic input/output
(I/O), counters, proto-arithmetic, and the like.
[0017] The microprogram 108 may be stored in a binary table, such
as that provided in a Read-Only Memory (ROM) storage module, where
the microcontroller 102 may read the microprogram 108 stored in the
ROM and may interpret commands from the microprogram 108. The
microprogram 108, which is executed by the microcontroller 102, may
be written in a special command language, which may be specially
designed and adjusted for the particular ALU 104 block for the
specific application to be implemented. An embodiment of a command
language will be discussed below, with reference to FIGS. 3 and 4.
Low-level functions/operations of the hierarchical function library
110, such as the ground level 110d functions/operations may be
hardware supported in the ALU 104, such as during an ALU 104
development/implementation stage. Higher level operations, such as
levels 110a-110c, may incorporate subprograms, where the
subprograms call upon lower-level functions and subfunctions, and
therefore may not require special hardware support in the ALU 104.
Thus, the top level 110a function implementation appears as a type
of microprogramming in the special command language. Such an
implementation may provide flexibility to the architecture, without
requiring substantive hardware requirements.
[0018] Referring now to FIG. 3, a block diagram of an architecture
of the microcontroller 102 is displayed in accordance with an
embodiment of the present disclosure. The microcontroller may
include four binary tables: one main binary table, PROGRAM ROM 300,
and three auxiliary binary tables, LABEL ROM 302, FUNCTION ROM 304,
and F_id DECODER 306.
[0019] The main binary table, PROGRAM ROM 300, may consist of
binary code of the microprogram 108 which may be executed by the
microcontroller 102 during runtime. LABEL ROM 302 may store
addresses of commands from a main table which were labeled in the
microprogram 108. FUNCTION ROM 304 may store addresses of the
functions/subfunctions as entry points that may be called during
execution of the microprogram. F_id DECODER 306 may be a binary
table which decodes indices of functions accessible for external
control into the start addresses of the PROGRAM ROM 300 table.
[0020] LABEL ROM 302 and FUNCTION ROM 304 may contain addresses
used in "go to" and "call" operators/commands in the microprogram
108. In one embodiment, the microprogram contains shorter indices
for LABEL ROM 302 and FUNCTION ROM 304, rather than actual
addresses, which tend to be longer. By utilizing shorter indices,
the compiled microprogram may be of a significantly reduced size.
For instance, a microprogram written for a fully hardwired
implementation of ECDSA operations (Elliptic Curve Digital
Signature Algorithm operations), such as signature generation and
signature verification, may have a size of less than 2 KB (with 1K
lines designated for common address space, and 12 bits for command
length). The maximum number of labels and functions allowed in the
microprogram 108 may be preset parameters. For example, the maximum
number of labels and functions may be preset to 32.
[0021] The microcontroller 102 may additionally include FLAGS 308,
CASE DECODER 310, ADR STACK 312, OPCODE DECODER 314, and CONTROL
CMD 316. FLAGS 308 may include external inputs which provide
feedback control from ALU 104 internal counters and comparators.
FLAGS 308 may also provide for control condition branching and for
the function calls in the microprogram 108. In one embodiment, only
one signal from FLAGS 308 is set as active, where the active
designation allows the active FLAG signal to transmit to the CASE
DECODER 310 submodule. The microprogram 108 may control the
switching between FLAGS 308 to select the active FLAG using
specified switching commands. For example, the maximum number of
FLAGS 308 may be preset to eight.
[0022] The ADR STACK 312 module may store return addresses for
functional calls. The depth for functional calls may be a preset
value. For example, the preset value for depth of functional calls
may be an integer value ranging between 2 and 5. The OPCODE DECODER
314 module may compute a next address having a command form of a
command stored in PROGRAM ROM 300 to be executed next by the
microcontroller 102. Additionally, the OPCODE DECODER 314 module
may send decoded data and control commands to the ALU 104. CONTROL
CMD 316, which constitutes output signals from the microcontroller
102, may be a flow/sequence of microprocessor data and commands
that may be further interpreted and decoded in a Command
Interpreter/Opcode Decoder module within the ALU 104.
[0023] The four binary tables (PROGRAM ROM 300, LABEL ROM 302,
FUNCTION ROM 304, and F_id DECODER 306) may include a compilation
of microprogram 108, written as a set of functions/subfunctions.
For instance, each function or subfunction may include a sequence
of commands to be executed by the microcontroller 102. Functions
and subfunctions may accomplish similar tasks, however,
subfunctions may be configured to not be called directly by an
external source. Thus, subfunction indices may not be compiled into
the F_id DECODER 306 binary table, since this table may decode
indices of functions accessible for external control.
[0024] Each command of a function/subfunction may consist of two
portions: the first portion may be a command and/or data
transferred to the ALU 104 which may be transferred to the ALU for
interpreting (e.g., decoding) and executing; the second portion may
be a control command for the microcontroller 102. The following is
a list of commands which may be used to write microprograms (where
"m" denotes a label, "d" denotes a code of operation for the ALU
104, and "par" denotes an auxiliary parameter): LABEL(m),
FUNCTION(m), SUBFUNCTION(m), SEND(d), RETURN, RETURN_IF.sub.--0,
RETURN_IF.sub.--1, STAND_BY, STOP, STOP_IF.sub.--0,
STOP_IF.sub.--1, SET_IF(d), CALL(m), JUMP(m), JUMP_IF.sub.--1(m),
JUMP_IF.sub.--0(m), SEND_EXTENDED_COM(d, par).
[0025] The above-mentioned list of commands may be defined as:
[0026] CALL(m)--call function/subfunction labeled with m; [0027]
SET_IF(d)--set IF signal to one of the feedback FLAGS 308 signals
is coming from the ALU 104. This may provide feedback with the ALU
104, and may be used for conditional commands; [0028] JUMP(m),
JUMPJF.sub.--1(m), JUMP_IF.sub.--0(m)--GOTO operator with label
(m), which may provide conditional or unconditional branching in
the program. For example, whether the command is conditional or
unconditional depends on the input IF value; [0029] RETURN,
RETURN_IF.sub.--0, RETURN_IF.sub.--1--RETURN operators, which may
provide conditional or unconditional transfer of control in the
program, depending on the input IF value; [0030] STOP,
STOP_IF.sub.--0, STOP_IF.sub.--1--STOP operators, which may provide
conditional or unconditional termination of the program, depending
on the input IF value.
[0031] The commands LABEL(m), FUNCTION(m), and SUBFUNCTION(m) may
be nonexecutable commands which may associate label "m" with the
command/function following the label, and additionally may give
names to the functions/subfunctions.
[0032] The microprogram 108 may include a sequence of commands. For
instance, each command may start with the SEND or SEND_EXTENDED_COM
commands, and then may continue with microcontroller control
commands. The transfer commands, i.e., SEND and SEND_EXTENDED_COM,
may be sent to the ALU 104 to be decoded and executed in the ALU
104. The SEND_EXTENDED_COM command may include an additional field
for a parameter to be sent to the ALU 104. For instance, the
parameter may include a memory address or an initial value for a
counter. This command may not continue with the control command,
such that the control command may be used for transferring the
parameter.
[0033] When executing the program, the executable commands may be
consecutively executed. For instance, one executable command may
executed per clock cycle. The program execution may start for the
function which is specified by the index with external input F_id.
During command execution, transferred commands and data/parameters
may be sent to the ALU 104 module for further execution. The ALU
104, in turn, may communicate with the microcontroller 102 by means
of FLAGS 308 signals. In one embodiment, the communication link
between the ALU 104 and the microcontroller 102 is by means of an
8-bit bus connecting the microcontroller with internal comparators
and other internal submodules within the ALU 104. Thus, through
this communication link, the microcontroller 102 may execute
conditional branching or GOTO/RETURN/STOP types of
transitions/operators depending on ALU 104 responses.
[0034] During compilation of the microprogram 108, the content of
the microprogram 108 may be written into one or more of four binary
tables/ROMs. The one or more of four binary tables/ROMs may either
be downloaded to an internal memory module in the microcontroller
102 or be synthesized in the microcontroller 102. All executable
commands may be enumerated in order as they appear in the program,
thus each executable program may get index ADDRESS, which may be
stored in PROGRAM ROM 300 at address ADDRESS. Additionally, the
executable commands may be associated with each label/name m from
the nonexecutable commands LABEL(m), FUNCTION(m), and
SUBFUNCTION(m), which may be the index of the following executable
command in the program, i.e., the index of the next command
following the label command or the function/subfunction
declaration.
[0035] Three auxiliary ROMS may contain addresses for the
corresponding indices. For instance, LABEL ROM 302 stores addresses
of the labels as the labels appear in the program. FUNCTION ROM 304
may store addresses of the functions/subfunctions as the
functions/subfunctions appear in the program. F_id DECODER ROM 306
may store addresses of the functions for allowable direct external
calls. By storing the table/ROM indices in the main program, rather
than actual addresses, the microprogram 108 may be of a
substantially reduced size. The capacity of each of the ROMs should
be sufficient to store the compiled programs. For example, to fully
implement ECDSA operations, the main program table may be 1024
lines, with 12 bits per each line, and 32 lines for labels and two
functional tables, with 10 bits per each line.
[0036] A sample microprogram written with basic commands may be
presented as:
TABLE-US-00001 FUNCTION("F0"); 1 SEND(cmd_1); SET_IF(port_C); 2
SEND(cmd_2); JUMP_IF_0("L0"); 3 SEND_EXTENDED_COM(cmd_3, 40); 4
SEND(cmd_D); RETURN; LABEL("L0"); 5 SEND(cmd_3); CALL("F1"); 6
SEND(cmd_B); STOP; SUBFUNCTION("F1") 7 SEND(cmd_1); SET_IF(port_D);
LABEL("L1"); 8 SEND_EXTENDED_COM(cmd_2, 31); 9 SEND(cmd_5); 10
SEND(cmd_6); JUMP_IF_1("L1"); 11 SEND(cmd_7); SET_IF(port_B); 12
SEND(cmd_8); JUMP_IF_0("L2"); 13 SEND(cmd_D); RETURN; LABEL("L2");
14 SEND(cmd_9); SET_IF(port_E); 15 SEND(cmd_A); RETURN_IF_0; 16
SEND(cmd_D); RETURN;
[0037] Based on the basic commands described above, a
microprogramming language may be designed for a developed ALU 104
specifically for a particular arithmetic/cryptographic application.
Developing the ALU 104 and implementing commands for the ALU 104
may be a combined and united process. For instance, a
microcontroller may be built specially designed and adjusted for
the particular ALU module, as a match for the specific
tasks/protocols that are desirably implemented. Higher-level
operations, including the top level 110a, the application level
110b, and the arithmetic level 110c, are implemented by calling
lower level functions/subfunctions, and thus, may not require
special hardware support in the ALU 104 or in implementation of the
top level protocols 110a.
[0038] The microprogramming language may be defined via generic
basic commands, as in the following example (where in the comments
"mem" means internal memory, and "rnd" means random):
TABLE-US-00002 IDLE SEND(cmd_0) // NOP MOVE_M_X SEND(cmd_1) // mem
-> X MOVE_M_Y SEND(cmd_2) // mem -> Y MOVE_M_XY SEND(cmd_3)
// mem -> X, mem -> Y SEED_X SEND(cmd_4) // X -> rnd
(seed) RAND_X SEND(cmd_5) // rnd -> X SWAP_X_Y SEND(cmd_8) // X
<--> Y COMPL_X SEND(cmd_9) // X = ~X bitwise ONE_X
SEND(cmd_D) // X = 000...0001 ...
The list of commands may be extended depending upon the desired
application and the particular ALU under development.
[0039] These commands may be utilized to developed a microprogram
for implementing high-level protocols. For example, see the
following microprogram:
TABLE-US-00003 SUBFUNCTION("SF_clean_io"); CLEAR_STS ;
READ_M(addr_of_seed); MOVE_M_X ; SEED_X ; ONE_X ; . . .
FUNCTION("F1_ecdsa_verification"); CLEAR_SIG ; READ_M(addr_of_input
); SAVE_M(addr_of_P_X .sup. ); READ_M(addr_of_input + 1);
SAVE_M(addr_of_P_Y .sup. ); READ_M(addr_of_input + 2); . . .
FUNCTION("F2_mul_point"); READ_M(addr_of_input ); SAVE_M(addr_of_K
); READ_M(addr_of_input + 1); SAVE_M(addr_of_Q_X );
READ_M(addr_of_input + 2); SAVE_M(addr_of_Q_Y );
READ_M(addr_of_input + 3); SAVE_M(addr_of_seed ); ONE_X; . . .
[0040] For another example of a microprogram, refer to FIG. 4,
where a portion of an ECDSA microprogram for executing by the
microcontroller 102 is displayed. The portion shown in FIG. 4 is an
excerpt from an approximately 1000 line program, which is written
for full hardware implementation of ECDSA operations (e.g.,
signature verification, signature generation, public key
generation, validation, and the like).
[0041] The present disclosure is described below with reference to
flowchart illustrations of methods. It will be understood that each
block of the flowchart illustrations and/or combinations of blocks
in the flowchart illustrations, can be implemented by computer
program instructions. These computer program instructions may be
provided to a processor of a general purpose computer, special
purpose computer, or other programmable data processing apparatus
to produce a machine, such that the instructions, which execute via
the processor of the computer or other programmable data processing
apparatus, create means for implementing the functions/acts
specified in the flowchart. These computer program instructions may
also be stored in a computer-readable tangible medium (thus
comprising a computer program product) that can direct a computer
or other programmable data processing apparatus to function in a
particular manner, such that the instructions stored in the
computer-readable tangible medium produce an article of manufacture
including instruction means which implement the function/act
specified in the flowchart.
[0042] Referring now to FIG. 5, a flow chart is displayed
illustrating a method 500. Method 500 may program a microprogram in
a command language in which each microprogram command includes a
first portion for indicating at least one of a command or data
transferred to an arithmetic logic unit (ALU), and a second portion
for including a control command to a controller 502. Method 500 may
compile the microprogram into a plurality of binary tables 504. The
microprogram may be configured for performing at least one of
hierarchical or a sequence of polynomial computations. Method 500
may execute the microprogram by a controller 506. Method 500 may
configure at least one of the plurality of binary tables for
including the code of the microprogram 508. Method 500 may
configure at least one of the plurality of binary tables for
storing at least one address of a command labeled in the
microprogram 510.
[0043] Method 500 may further configure at least one of the
plurality of binary tables for storing addresses of at least one of
a function or a subfunction as an entry point for calling during
execution of the microprogram. Method 500 may further configure at
least one of the plurality of binary tables for decoding indices of
functions accessible for external control. Method 500 may further
perform at least one of editing the microprogram or generating
binary tables, during which a controller netlist remains unchanged.
Compiling the microprogram into a plurality of binary tables of
method 500 may include compiling the microprogram into a PROGRAM
ROM binary table, a LABEL ROM binary table, a FUNCTION ROM binary
table, and an F_id DECODER binary table. Additionally, compiling
the microprogram into a plurality of binary tables of method 500
may include compiling the microprogram from a hierarchical function
library. Further, method 500 may store separate blocks of
subprograms and subfunctions in at least four levels of subprograms
and subfunctions, the at least four levels include a top level for
including protocols, an application level for including relatively
complex operational functionality, an arithmetic level for
including operational functionality, and a ground level for
including initial ALU operations. Method 500 may further provide
hardware support for only the ground level. For instance, the top
level, the application level, and the arithmetic level may not
require hardware support.
[0044] The arithmetic module architecture 100 may be configured to
process and implement hierarchical arithmetical/polynomial
computations typical for various cryptosystems and for common
cryptographic protocols. For example, the arithmetic module
architecture 100 may be configured to process and implement
computations from ECC/HECC (Elliptic Curve
Cryptography/HyperElliptic Curve Cryptography) cryptosystems over a
finite field GF(2.sup.n) or Z.sub.p for relatively large integers n
and p (or more generally over G(p.sup.n), where p is a relatively
small prime number, e.g., p=3 or p=7, and n is a relatively large
number). Additionally, the arithmetic module architecture 100 may
be configured to process and implement computations from RSA
(Rivest-Shamir-Adelman) cryptosystems over Z.sub.n, where n=p*q,
for relatively large prime numbers p and q. Further, the arithmetic
module architecture 100 may be configured to process and implement
computations from DH-based (Diffie-Hellman) cryptographic protocols
over Z.sub.p, including other algebraic groups with relatively
difficult discrete logarithm computation. Still further, the
arithmetic module architecture 100 may be configured to process and
implement computations from ECC/HECC pairing-based cryptography
over GF(2.sup.n) or Z.sub.p (e.g., multiparty key exchange schemes,
identity-based encryption/decryption, and the like). It is
appreciated that the arithmetic module architecture 100 may be
configured to process and implement computations from other
cryptographic applications and protocols without departing from the
scope of the present disclosure.
[0045] In the present disclosure, the methods disclosed may be
implemented as sets of instructions or software readable by a
device. Such a software package may be a computer program product
which employs a computer-readable storage medium including stored
computer code which is used to program a computer to perform the
disclosed function and process of the present disclosure. The
computer-readable medium may include, but is not limited to, any
type of conventional floppy disk, optical disk, CD-ROM, magnetic
disk, hard disk drive, magneto-optical disk, ROM, RAM, EPROM,
EEPROM, magnetic or optical card, or any other suitable media for
storing electronic instructions.
[0046] It is believed that the present invention and many of its
attendant advantages will be understood by the foregoing
description, and it will be apparent that various changes may be
made in the form, construction and arrangement of the components
thereof without departing from the scope and spirit of the
invention or without sacrificing all of its material advantages.
The form herein before described being merely an explanatory
embodiment thereof, it is the intention of the following claims to
encompass and include such changes.
* * * * *