1 |
11 |
ruschi |
\documentclass{ruschidoc}
|
2 |
|
|
|
3 |
|
|
\usepackage[
|
4 |
|
|
bookmarks,
|
5 |
|
|
plainpages={false}]{hyperref}
|
6 |
|
|
|
7 |
|
|
\usepackage[
|
8 |
|
|
style=altlist,
|
9 |
|
|
hyper=true,
|
10 |
|
|
number=none,
|
11 |
|
|
acronym=true,
|
12 |
|
|
header=none]{glossary}
|
13 |
|
|
\usepackage{capt-of}
|
14 |
|
|
|
15 |
|
|
%%% Water mark
|
16 |
|
|
%\usepackage{draftwatermark}
|
17 |
|
|
%\SetWatermarkText{\shortstack{DRAFT}}
|
18 |
|
|
%\SetWatermarkScale{0.9}
|
19 |
|
|
%\SetWatermarkLightness{0.85}
|
20 |
|
|
|
21 |
|
|
\makeacronym
|
22 |
|
|
\makeglossary
|
23 |
|
|
\input{acronym}
|
24 |
|
|
\input{glossary}
|
25 |
|
|
\bibliographystyle{IEEEtran}
|
26 |
|
|
|
27 |
|
|
%%%%%%%%%%%%%%%%%
|
28 |
|
|
% Document variables
|
29 |
|
|
%%%%%%%%%%%%%%%%%
|
30 |
|
|
\docDate{ \today }
|
31 |
|
|
\docID{avs\_aes\_doc}
|
32 |
|
|
\docRevision{0.5}
|
33 |
|
|
\docStatus{Final}
|
34 |
|
|
\docTitle{\mbox{AES 128/192/256 (ECB)} \mbox{Avalon\rtm-MM Slave}}
|
35 |
|
|
\keywords{Avalon, bus, slave, cryptography, AES, ecb, IP core }
|
36 |
|
|
|
37 |
|
|
\authorName{\mbox{Thomas Ruschival} \\ and opencores.org}
|
38 |
|
|
\authorURL{www.opencores.org}
|
39 |
|
|
\authorAddress{\mbox{}}
|
40 |
|
|
\authorEmail{ruschi@opencores.org}
|
41 |
|
|
|
42 |
|
|
|
43 |
|
|
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|
44 |
|
|
% FORMAT: Rev | Chapter | Description | Date | Reviewer \\
|
45 |
|
|
\revisionList{
|
46 |
|
|
0.1 & all & initial document & 2009/02/01 & T. Ruschival \\
|
47 |
|
|
0.2 & all & added interrupt & 2009/03/25 & T. Ruschival \\
|
48 |
|
|
0.3 & all & added generics & 2009/04/20 & T. Ruschival \\
|
49 |
|
|
0.4 & all & cleanup for opencores.org & 2009/05/20 & T. Ruschival \\
|
50 |
|
|
0.5 & all & final release & 2010/03/07 & T. Ruschival \\
|
51 |
|
|
0.6 & 3,6 & fixed memory map, added testbench description & 2010/04/02 & T. Ruschival \\
|
52 |
|
|
}
|
53 |
|
|
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|
54 |
|
|
|
55 |
|
|
|
56 |
|
|
\begin{document}
|
57 |
|
|
\maketitle
|
58 |
|
|
\newpage
|
59 |
|
|
\tableofcontents
|
60 |
|
|
\newpage
|
61 |
|
|
|
62 |
|
|
\section{Introduction}
|
63 |
|
|
\label{sec:intro} The \AES is a symmetric block cypher operating on fixed block sizes
|
64 |
|
|
of 128 Bit and is specified for key sizes of 128, 192 and 256 Bit designed by Joan
|
65 |
|
|
Daemen and Vincent Rijmen. The algorithm was standardized by \NIST. For more
|
66 |
|
|
information on the algorithm see \cite{NIST:Fips197}.\\
|
67 |
|
|
This component implements an AES encryption decryption datapath in \ECB mode with
|
68 |
|
|
either 128,192 or 256 Bit keys. The keylength is determined by generics at compile
|
69 |
|
|
time. Also the decryption datapath can be disabled by generics if it is not needed
|
70 |
|
|
for the application.\\
|
71 |
|
|
The component provides an Avalon\rtm\ Memory Mapped (Avalon-MM) slave interface to
|
72 |
|
|
connect to an Altera\rtm\ Avalon\rtm\ switch fabric. The Avalon\rtm\ interface is
|
73 |
|
|
implemented in a way that it can also be used to connect to a Whishbone master if the
|
74 |
|
|
signals are correctly mapped, see \cite{Wiki:AvWb}. For further information about the
|
75 |
|
|
Whishbone bus refer to \cite{OC:WBspec}. \\
|
76 |
|
|
|
77 |
|
|
\section{Interface}
|
78 |
|
|
\label{sec:interface}
|
79 |
|
|
The AES core is accessed by the interface described in this section. An Avalon\rtm\
|
80 |
|
|
interface was chosen for its simplicity and compatibility with wishbone. Furthermore
|
81 |
|
|
Avalon\rtm\ defines interrupt request signals for slaves which would be separate
|
82 |
|
|
signals in a Wishbone implementation.The component can be used both in polling
|
83 |
|
|
mode or can provide an interrupt for signalling. \\
|
84 |
|
|
Unfortunately Avalon\rtm\ is an Altera\rtm\ proprietary technology. The actual AES
|
85 |
|
|
core however is a selfcontained entity and can be embedded into other \SoC\ bus
|
86 |
|
|
interfaces as well or used indepentently.
|
87 |
|
|
|
88 |
|
|
\subsection{Configuration Generics}
|
89 |
|
|
\label{sec:generics}
|
90 |
|
|
The AES core can be configured by generics shown in table \ref{tab:generics},
|
91 |
|
|
consequently they are provided by the Avalon\rtm\ interface.
|
92 |
|
|
|
93 |
|
|
\begin{tabularx}{\textwidth}{|p{33mm}|p{25mm}|X|}
|
94 |
|
|
\hline
|
95 |
|
|
\bf{Generic name} & \bf{type} & \bf{Description}\\ \hline
|
96 |
|
|
\texttt{KEYLENGTH} \label{gen:keylength} & NATURAL & Size of initial userkey. Must be 128, 192 or 256 \footnotemark[1] . \\ \hline
|
97 |
|
|
\texttt{DECRYPTION} \label{gen:decryption} & BOOLEAN & Enables the instantiation of the decrypt datapath if true. \\
|
98 |
|
|
\hline
|
99 |
|
|
\end{tabularx}
|
100 |
|
|
\footnotetext[1]{All other values raise a compilation failure}
|
101 |
|
|
\captionof{table}{Component generics}
|
102 |
|
|
\label{tab:generics}
|
103 |
|
|
Note: \texttt{KEYLENGTH} of 192 fail synthesis with Xilinx ISE \rtm\ because of division by 6 in key schedule that cannot be mapped to shift operations (\texttt{keyexpansion.vhd}).
|
104 |
|
|
|
105 |
|
|
\subsection{Signals}
|
106 |
|
|
\label{sec:signals}
|
107 |
|
|
The Avalon\rtm\-MM Slave interface is described in \cite{Altera:Avalon}, the component
|
108 |
|
|
implements the signals shown in table \ref{tab:signals}. All signals are synchronous,
|
109 |
|
|
sampled at the rising edge of the clock. The type for all signals is \texttt{IEEE1164
|
110 |
|
|
std\_logic} or \texttt{std\_logic\_vector}. For signals wider that 1 Bit the range
|
111 |
|
|
is \MSB\ \texttt{downto} \LSB\. \\
|
112 |
|
|
This components has only output signals driven by registers no input signals are directly combinatorially connected to the
|
113 |
|
|
output signals, thus combinational loops are avoided. All signals are active
|
114 |
|
|
high. This component does not support burst transfers.
|
115 |
|
|
|
116 |
|
|
\begin{tabularx}{\textwidth}{|p{30mm}|p{11mm}|p{11mm}|X|}
|
117 |
|
|
\hline
|
118 |
|
|
\bf{Signal name} & \bf{Width} & \bf{In/Out} & \bf{Description}\\ \hline
|
119 |
|
|
\texttt{clk} \label{sig:clk} & 1 & in & Avalon\rtm\ bus clock, also used to drive the core. \\ \hline
|
120 |
|
|
\texttt{reset} \label{sig:reset}& 1 & in & \emph{Synchronous} reset signal for Avalon\rtm\ bus interface.
|
121 |
|
|
The core itself is designed without need for reset signals.
|
122 |
|
|
\\ \hline
|
123 |
|
|
\texttt{writedata} \label{sig:writedata} & 32 & in & Input data to write to location designated by \texttt{address}. Bit 31 is most significant Bit.
|
124 |
|
|
\\ \hline
|
125 |
|
|
\texttt{address} \label{sig:address} & 5 & in & Word offset to the components base address. The memory map of the component for the
|
126 |
|
|
respective offest is described in \ref{sec:memmap}. Only full 32-Bit words can be addressed no byte addressing is implemented.
|
127 |
|
|
\\ \hline
|
128 |
|
|
\texttt{write}\footnotemark[1] \label{sig:write} & 1 & in & If asserted enable write of data at \texttt{writedata} to location designated by \texttt{address}.
|
129 |
|
|
\\ \hline
|
130 |
|
|
\texttt{read}\footnotemark[1] \label{sig:read} & 1 & in & If asserted output data at location designated by \texttt{address} to \texttt{readdata}.
|
131 |
|
|
\\ \hline
|
132 |
|
|
\texttt{readdata} \label{sig:readdata} & 32 & out & Data output port for reading data at the location defined by \texttt{address}. Bit 31 is most significant Bit.
|
133 |
|
|
\\ \hline
|
134 |
|
|
\texttt{waitrequest} \label{sig:waitrequest} & 1 & out & Asserted if writedata was not accepted, this is the case if the keyexpansion is
|
135 |
|
|
not yet complete and a new is written to the \texttt{KEY} address range without previous deassertion of the \texttt{KEY\_VALID} Bit
|
136 |
|
|
\\ \hline
|
137 |
|
|
\texttt{irq}\label{sig:irq} & 1 & out & If Interrupt behaviour is enabled \texttt{IRQ}
|
138 |
|
|
will be asserted when the operation has terminated. For use of interrupt see \ref{sec:irq}
|
139 |
|
|
\\ \hline
|
140 |
|
|
\end{tabularx}
|
141 |
|
|
\footnotetext[1]{\texttt{read} and \texttt{write} are mutually exclusive and must not be asserted simultanously.}
|
142 |
|
|
\label{tab:signals}
|
143 |
|
|
\captionof{table}{Avalon\rtm\ Bus interface signals}
|
144 |
|
|
|
145 |
|
|
|
146 |
|
|
\section{Memory Map}
|
147 |
|
|
\label{sec:memmap}
|
148 |
|
|
The AES core Avalon\rtm\ slave has an address space of 31 words accessable through the
|
149 |
|
|
offset described by the signal \texttt{address}, see \ref{sig:address}. This address
|
150 |
|
|
space is devided into three main sections for the 4-word input data, the 4-word
|
151 |
|
|
result of the operation and the user key. The actual lenght of the userkey can vary
|
152 |
|
|
between 4, 6 and 8 words depending on the keysize. For control signals and status
|
153 |
|
|
information of the component and a control word is provided. The memory mapping is
|
154 |
|
|
descibed in table \ref{tab:memmap}.\\
|
155 |
|
|
|
156 |
|
|
\begin{tabularx}{\textwidth}{|p{18mm}|p{14mm} |X|}
|
157 |
|
|
\hline
|
158 |
|
|
\bf{Offset} & \bf{Name} & \bf{Description}\\ \hline
|
159 |
|
|
\texttt{0x00-0x07} & \texttt{KEY} & Initial user key that will be used for encryption and decryption.
|
160 |
|
|
The most significant word is written to offset \texttt{0x00}. This memory section is \emph{write-only} to the Avalon\rtm\ interface.\\
|
161 |
|
|
\hline
|
162 |
|
|
\texttt{0x08-0x0B} & \texttt{DATA} & Input data, can be either interpreted as cyphertext for decryption or plain text for encryption.
|
163 |
|
|
The most significant word shall be written to offset \texttt{0x08}. This memory section is \emph{write-only} to the Avalon\rtm\ interface. \\
|
164 |
|
|
\hline
|
165 |
|
|
\texttt{0x10-0x13} & \texttt{RESULT} & Result of the operation. The most significant word of the result at offset \texttt{0x10}.
|
166 |
|
|
This memory section is \emph{read-only} to the Avalon\rtm\ Interface. \\
|
167 |
|
|
\hline
|
168 |
|
|
\texttt{0x14-0x1E} & --- & reserved \\ \hline
|
169 |
|
|
\texttt{0x1F} & \texttt{CTRL} & Control and status word of the component can be read and written. Detailed description see \ref{sec:ctrl}\\
|
170 |
|
|
\hline
|
171 |
|
|
\end{tabularx}
|
172 |
|
|
\label{tab:memmap}
|
173 |
|
|
\captionof{table}{Memory map of the AES core Avalon\rtm\ slave}
|
174 |
|
|
|
175 |
|
|
\subsection{Control Register}
|
176 |
|
|
\label{sec:ctrl}
|
177 |
|
|
The AES Core offers the register \texttt{CTRL} to control the function of the core
|
178 |
|
|
and poll its status. The control register can be accessed in read and write mode.
|
179 |
|
|
When wrriting to the register reserved Bits shall be assigned a value of \texttt{0}.
|
180 |
|
|
Individual Bits have following functionality decribed in table \ref{tab:ctrlreg}. \\
|
181 |
|
|
In case of a Avalon\rtm\ Bus reset this register is set to \texttt{0x00000000} thus
|
182 |
|
|
invalidating all previously written keys and resetting the AES core.
|
183 |
|
|
|
184 |
|
|
\begin{tabularx}{\textwidth}{|p{13mm}|p{18mm} |X|}
|
185 |
|
|
\hline
|
186 |
|
|
\bf{Offset} & \bf{Name} & \bf{Description}\\ \hline
|
187 |
|
|
\texttt{31-8} & --- & reserved \\ \hline
|
188 |
|
|
\texttt{7} &\texttt{KEY\_VALID} &If asserted key data in the \texttt{KEY} memory range is regarded valid and will be expanded to roundkeys.
|
189 |
|
|
When deasserted all keys are invalidated and the current operation of the core is aborted. It must be asserted as long as the key shall be
|
190 |
|
|
used for either encryption or decryption. This bit must be cleared for one clock cylce to load a new key. \\ \hline
|
191 |
|
|
\texttt{6} & \texttt{IRQ\_ENA} & Enable use of the interrupt request signal. If asserted the component will set \texttt{IRQ} after
|
192 |
|
|
completing an operation. If not set the component operates in polling mode only.\\ \hline
|
193 |
|
|
\texttt{5-2} & --- &reserved \\ \hline
|
194 |
|
|
\texttt{1} & \texttt{DEC} \footnotemark[1] & If asserted memory content of the \texttt{DATA} range is regarded to be valid and will be
|
195 |
|
|
\emph{decrypted}. This Bit shall only be deasserted externally if a running AES operation is aborted by deasserting \texttt{KEY\_VALID}. 1
|
196 |
|
|
It will be set \texttt{0} by the core to signal completion of the operation.\\ \hline
|
197 |
|
|
\texttt{0} & \texttt{ENC} \footnotemark[1] & If asserted memory content of the \texttt{DATA} range is regarded to be valid and will be
|
198 |
|
|
\emph{encrypted}. This Bit shall only be deasserted externally if a running AES operation is aborted by deasserting \texttt{KEY\_VALID}.
|
199 |
|
|
It will be set \texttt{0} by the core to signal completion of the operation. \\ \hline
|
200 |
|
|
\end{tabularx}
|
201 |
|
|
\footnotetext[1]{\texttt{ENC} and \texttt{DEC} are mutually exclusive and must not be asserted simultanously.}
|
202 |
|
|
\label{tab:ctrlreg}
|
203 |
|
|
\captionof{table}{Bits in the control register}
|
204 |
|
|
|
205 |
|
|
|
206 |
|
|
\section{Protocol Sequence}
|
207 |
|
|
\label{sec:usage}
|
208 |
|
|
The AES component appears as memory mapped peripheral. All writes are fundamental slave write transfers, see \cite{Altera:Avalon} and take one
|
209 |
|
|
clock cycle of the Avalon\rtm\ bus clock \texttt{clk}. It is not necessary to write all words of a input parameter successively or in one transfer.
|
210 |
|
|
Bursts are not supported.\\
|
211 |
|
|
\\
|
212 |
|
|
Before any AES operation can be started the initial userkey has to be written to
|
213 |
|
|
\texttt{KEY} segment of the memory map.After the user key is transferred
|
214 |
|
|
to the component the \texttt{KEY\_VALID} Bit must be set to start the key
|
215 |
|
|
expansion. This Bit can be set simultanously with \texttt{DEC} or \texttt{ENC} Bit of
|
216 |
|
|
the control register. To invalidate the previous key and use another key the
|
217 |
|
|
\texttt{KEY\_VALID} must be deasserted for at least one Avalon\rtm\ bus clock cycle
|
218 |
|
|
During this cycle the new key can already be transferred.\\
|
219 |
|
|
\\
|
220 |
|
|
Once a key is passed and marked valid data blocks can be transferred to the
|
221 |
|
|
\texttt{DATA} segment of the memory map.
|
222 |
|
|
The AES operation is started by asserting the \texttt{ENC} Bit for
|
223 |
|
|
encryption or \texttt{DEC} Bit for decryption.
|
224 |
|
|
While asserting \texttt{ENC} or \texttt{DEC} the \texttt{KEY\_VALID} Bit must be
|
225 |
|
|
kept asserted.\\
|
226 |
|
|
The \texttt{ENC} or \texttt{DEC} Bit respectively is deasserted by the component
|
227 |
|
|
after completing the requested operation.
|
228 |
|
|
The result of the operation can be read from the \texttt{RESULT} area of the memory
|
229 |
|
|
and is not cleared. It will be overwritten by succeeding operations.
|
230 |
|
|
|
231 |
|
|
The underlying AES core uses the \FSM\ shown in \ref{fig:aesFSM} for processing of
|
232 |
|
|
the data. The signals \texttt{data\_stable} and \texttt{key\_stable} are accessible
|
233 |
|
|
over the control status word \texttt{CTRL} \ref{sec:ctrl}. \texttt{key\_ready} is a
|
234 |
|
|
signal driven by the keygenerator when all keys are expanded. The signal
|
235 |
|
|
\texttt{round\_index} is the counter for the rounds and the address to select a
|
236 |
|
|
roundkey. \\
|
237 |
|
|
\texttt{NO\_ROUNDS} is the total number of rounds the processing takes, a constant
|
238 |
|
|
defined by the generic \texttt{KEYLENGTH} \ref{sec:generics}. The AES standard
|
239 |
|
|
in\cite{NIST:Fips197} defines 10 rounds for 128 Bit key, 12 rounds for a 192 Bit key
|
240 |
|
|
and 14 rounds for a 265 Bit key.\\
|
241 |
|
|
Thus depending on the keylength the processing of a datablock needs at maximum 15
|
242 |
|
|
clockcycles from \texttt{data\_stable=1} to completion, if the key is already expanded.
|
243 |
|
|
|
244 |
|
|
\begin{figure}[!ht]
|
245 |
|
|
\centering
|
246 |
|
|
\includegraphics[width=100mm]{encrypt_FSM}
|
247 |
|
|
\caption{Finite State Machine of encryption and decryption process}
|
248 |
|
|
\label{fig:aesFSM}
|
249 |
|
|
\end{figure}
|
250 |
|
|
|
251 |
|
|
|
252 |
|
|
\subsection{Interrupt Behaviour}
|
253 |
|
|
\label{sec:irq}
|
254 |
|
|
By setting \texttt{IRQ\_ENA} in the control register \ref{sec:ctrl} the
|
255 |
|
|
component is configured to issue interrupt requests.
|
256 |
|
|
If \texttt{IRQ\_ENA} is asserted the interrupt request \texttt{IRQ} \ref{sig:irq} will be set when the
|
257 |
|
|
computation has completed in addition to clearing the \texttt{ENC} or \texttt{DEC}
|
258 |
|
|
Bit.
|
259 |
|
|
The \texttt{IRQ} \ref{sig:irq} signal will remain set until clearing \texttt{IRQ\_ENA}
|
260 |
|
|
or a read operation on the \texttt{RESULT} area of the components address range.
|
261 |
|
|
|
262 |
|
|
|
263 |
|
|
\section{Ressource Usage and Throughput}
|
264 |
|
|
\label{sec:ressources}
|
265 |
|
|
|
266 |
|
|
The Avalon\rtm\ interface communicates a 32-Bit DWORD per clock cycle. Therefore a key is transmitted in 4 to 8 cyles
|
267 |
|
|
plus one cyle to activate keyexpansion with the control word \ref{sec:ctrl}. A payload datablock or the result consist
|
268 |
|
|
always of 4 DWORDs, thus it takes 4 cyles to send data to the core, one cycle to activate the computation with the
|
269 |
|
|
control register \ref{sec:ctrl} and 4 cycles to retrieve the data.
|
270 |
|
|
|
271 |
|
|
The keyexpansion component computes one column of a roundkey each clock cylce. AES takes, depending on the keylength,
|
272 |
|
|
10, 12 or 14 roundkeys with each 4 columns, see \cite{NIST:Fips197}. The keyexpansion therefore takes 40, 48 or 56
|
273 |
|
|
cycles until the encryption or decryption can start. The roundkeys are stored until invalidated, see \ref{sec:usage}
|
274 |
|
|
thus this step is is only needed once after power-up until the key changes.
|
275 |
|
|
|
276 |
|
|
The AES-core computes one iteration (round) of the Rijndael-Algorithm each clock cycle, thus a 128 Bit datablock is
|
277 |
|
|
encrypted or decrypted in 10, 12 or 14 cylces plus an initial round.
|
278 |
|
|
|
279 |
|
|
The maximum throughput $T_{max}[Bits]$ depends on the maximum operation frequency $f_{max}$ and the keylength which
|
280 |
|
|
influences the number of rounds $N_{rnd} \epsilon \lbrace 10,12,14 \rbrace $.
|
281 |
|
|
\begin{equation}
|
282 |
|
|
T_{max}=\frac{ (1+N_{rnd}) \cdot 128 Bit}{f_{max}}
|
283 |
|
|
\label{eqn:tmax}
|
284 |
|
|
\end{equation}
|
285 |
|
|
|
286 |
|
|
Note: Equation \ref{eqn:tmax} assumes that the roundkeys are already generated and does not include the constant of 4+1+4
|
287 |
|
|
Avalon\rtm\ bus cylces for transmission of data, activation and result retrieval.
|
288 |
|
|
|
289 |
|
|
|
290 |
|
|
\subsection{Exemplary FPGA implementations}
|
291 |
|
|
|
292 |
|
|
The component has only be implemented and tested on an Altera\rtm\ CycloneII EP2C35
|
293 |
|
|
FPGA. For this setup a Makefile is provided in \texttt{./sys/AlteraQuartus9.1}. All
|
294 |
|
|
other values in the table are only results of synthesis\footnotemark[0] and are not
|
295 |
|
|
verified on actual hardware.
|
296 |
|
|
|
297 |
|
|
|
298 |
|
|
\footnotetext[0]{Synthesized with Altera\rtm\ QuartusII\rtm\ Web edition Version 9.1 or Xilinx\rtm\ ISE 9.1 Webpack}
|
299 |
|
|
|
300 |
|
|
The design is kept mostly vendor independent in generic VHDL. For Altera\rtm\ chips the
|
301 |
|
|
AES SubByte component is specially designed using M4K Blockrams as dual-port ROM. For
|
302 |
|
|
non-Altera\rtm\ FPGAs a second VHDL architecture exists also trying to make use of
|
303 |
|
|
ROM functions of the target chips however the success varies on RTL compiler
|
304 |
|
|
capabilities.
|
305 |
|
|
|
306 |
|
|
\begin{tabularx}{\textwidth}{|p{30mm}|X|p{20mm}|p{30mm}|p{18mm}|}
|
307 |
|
|
\hline
|
308 |
|
|
\bf{Configuration} & \bf{Target FPGA}\footnotemark[1] & \bf{LE / Slices} & \bf{HW RAM} & $\mathbf{f_{max}[Mhz]}$ \\ \hline
|
309 |
|
|
\multirow{4}{30mm}{256 Bit Key, encrypt + decrypt} & \mbox{Xilinx\rtm\ Spartan3A} XC3S1400A-5FG484 & - / 1609 & 18 RAMB16BWE & 91 \\ \cline{2-5}
|
310 |
|
|
& \mbox{Xilinx\rtm\ Virtex5} XC5VLX30-3FF324 & - / 297 & \mbox{18 18k-Blocks} \mbox{4 36k-Blocks} & 224 \\ \cline{2-5}
|
311 |
|
|
& \mbox{Altera\rtm\ CylconeII} EP2C35F484C8 & 1937 / - & \mbox{39912 Bits} in \mbox{22 M4K-Blocks} & 65 \\ \cline{2-5}
|
312 |
|
|
& \mbox{Altera\rtm\ StratixII} EP2S30F484C5 & 585 / - & \mbox{39912 Bits} in \mbox{22 M4K-Blocks} & 103 \\
|
313 |
|
|
\hline
|
314 |
|
|
%%%%%%
|
315 |
|
|
\multirow{2}{30mm}{128 Bit Key, encrypt + decrypt} & \mbox{Xilinx\rtm\ Spartan3A} XC3S1400A-5FG484 & - / 1523 & 18 RAMB16BWE & 91 \\ \cline{2-5}
|
316 |
|
|
& \mbox{Altera\rtm\ CylconeII} EP2C35F484C8 & 1776 / - & \mbox{39912 Bits} in \mbox{22 M4K-Blocks} & 65 \\
|
317 |
|
|
\hline
|
318 |
|
|
%%%%%%
|
319 |
|
|
\multirow{4}{30mm}{256 Bit Key, encrypt} & \mbox{Xilinx\rtm\ Spartan3A} XC3S1400A-5FG484 & - / 680 & 14 RAMB16BWE & 159 \\ \cline{2-5}
|
320 |
|
|
& \mbox{Xilinx\rtm\ Virtex5} XC5VLX30-3FF324 & - / 297 & \mbox{10 18k-Blocks} \mbox{4 36k-Blocks} & 268 \\ \cline{2-5}
|
321 |
|
|
& \mbox{Altera\rtm\ CylconeII} EP2C35F484C8 & 969 / - & \mbox{22528 Bits} in \mbox{14 M4K} & 97 \\ \cline{2-5}
|
322 |
|
|
& \mbox{Altera\rtm\ StratixII} EP2S30F484C5 & 524 / - & \mbox{22528 Bits} in \mbox{ 14 M4K} & 145 \\
|
323 |
|
|
\hline
|
324 |
|
|
%%%%%%
|
325 |
|
|
\multirow{2}{30mm}{128 Bit Key, encrypt} & \mbox{Xilinx\rtm\ Spartan3A} XC3S1400A-5FG484 & - / 594 & 14 RAMB16BWE & 159 \\ \cline{2-5}
|
326 |
|
|
& \mbox{Altera\rtm\ CylconeII} EP2C35F484C8 & 797 / - & \mbox{22528 Bits} in \mbox{ 14 M4K} & 95 \\ \cline{2-5}
|
327 |
|
|
\hline
|
328 |
|
|
|
329 |
|
|
\end{tabularx}
|
330 |
|
|
\footnotetext[1]{This table is not meant to be a benchmark between FPGAs of different vendors, it is only a rough
|
331 |
|
|
estimation for the user of the core.
|
332 |
|
|
The FPGA families cannot be compared easily, see also \cite{Xilinx:wp284} and \cite{Altera:01007}for further details. }
|
333 |
|
|
\label{tab:ressources}
|
334 |
|
|
\captionof{table}{ressource usage on different targets and configuration}
|
335 |
|
|
|
336 |
|
|
All of the above configurations in table \ref{tab:ressources} use hardware key
|
337 |
|
|
expansion. Downloading of software generated roundkeys is not yet supported. The
|
338 |
|
|
decryption and encryption datapaths share a common keyexpansion block, mulitplexing
|
339 |
|
|
the address signals is one of the main reasons for regression of the maximum
|
340 |
|
|
frequency $f_{max}$ of the configuration compared to encryption only versions.
|
341 |
|
|
|
342 |
|
|
\section{Simulation and Software Driver}
|
343 |
|
|
\label{sec:simdriv}
|
344 |
|
|
\subsection{Testbench}
|
345 |
|
|
\label{sec:testbench}
|
346 |
|
|
In \texttt{./bench/VHDL/} a ``selfchecking testbench'' is provided which runs tests
|
347 |
|
|
for a default \texttt{TESTKEYSIZE} is 256 Bit . For different key lengths the
|
348 |
|
|
constant \texttt{TESTKEYSIZE} has to be changed appropriately. Expected results for
|
349 |
|
|
all testcases and key lengths are included. The expected results were generated by
|
350 |
|
|
AES Calculator applet, written by Lawrie Brown from ADFA, Canberra Australia \cite{LaBr05}. The
|
351 |
|
|
testbench consists of a sequence of 5 test cases:
|
352 |
|
|
\begin{enumerate}
|
353 |
|
|
\item load key1, load data1, encrypt : (basic encryption test)
|
354 |
|
|
\item key1, data1, decrypt: (basic decryption test)
|
355 |
|
|
\item key1, data1, encrypt: (test if internal state was changed)
|
356 |
|
|
\item key1, data2, encrypt: (encryption test with new data)
|
357 |
|
|
\item key2, data2, encrypt: (encryption test with new key)
|
358 |
|
|
\end{enumerate}
|
359 |
|
|
|
360 |
|
|
\subsubsection{Simulation}
|
361 |
|
|
\label{sec:simulation}
|
362 |
|
|
The component library is ``\texttt{avs\_aes\_lib}''. All files are expected to be
|
363 |
|
|
compiled into this library as all files depend at least on the package
|
364 |
|
|
\texttt{avs\_aes\_lib.avs\_aes\_pkg}. \\
|
365 |
|
|
A Makefile for Mentor Graphics\rtm\ Modelsim\rtm\ is given in \texttt{./sim/}. The
|
366 |
|
|
default make target \texttt{simaes} will create the library
|
367 |
|
|
``\texttt{avs\_aes\_lib}'' and a ``\texttt{work}'' library, compile all files and run
|
368 |
|
|
a testbench. \\
|
369 |
|
|
|
370 |
|
|
\subsection{Software Driver}
|
371 |
|
|
\label{sec:software}
|
372 |
|
|
This AES Core Avalon\rtm\ slave was also tested on a NiosII\rtm\ processor. To use
|
373 |
|
|
it in software a simple driver is provided in \texttt{./sw/} among with an example
|
374 |
|
|
program of the basic usage. Find more detailed description in the doxygen documentation in \texttt{./doc/sw/html}\\
|
375 |
|
|
The driver consits of the two files \texttt{avs\_aes.c} and \texttt{avs\_aes.h}.
|
376 |
|
|
\subsubsection{Configuration}
|
377 |
|
|
To be adapted to different address mappings and key sizes two macros are use in \texttt{avs\_aes.h}:
|
378 |
|
|
\begin{tabularx}{\textwidth}{|p{25mm}|p{25mm} |X|}
|
379 |
|
|
\hline
|
380 |
|
|
\bf{define} & \bf{default} & \bf{Description}\\ \hline
|
381 |
|
|
\texttt{KEYWORDS} & \texttt{8} & Key size in 32 Bit words \\
|
382 |
|
|
\hline
|
383 |
|
|
\texttt{AES\_BASEADDR} & \texttt{0x40000} & Base address at which the AES Core is mapped to the Avalon\rtm\ switchfabric \\
|
384 |
|
|
\hline
|
385 |
|
|
\end{tabularx}
|
386 |
|
|
\label{tab:macros}
|
387 |
|
|
\captionof{table}{user changeable macros in header}
|
388 |
|
|
|
389 |
|
|
\subsubsection{Compilation}
|
390 |
|
|
Yes indeed very difficult to compile two files and one header..... try this one:\\
|
391 |
|
|
\texttt{GCCNIOS -I. -o test aes\_tester.c avs\_aes.c}
|
392 |
|
|
|
393 |
|
|
Of course you need a cross compiler, or just use the Nios2 IDE.
|
394 |
|
|
|
395 |
|
|
|
396 |
|
|
|
397 |
|
|
\section{The Inner Core}
|
398 |
|
|
\label{sec:core}
|
399 |
|
|
The algorithmic core is devided into two seperate datapaths one for encryption and a
|
400 |
|
|
second for decryption operation. The two datapaths are independent, however they
|
401 |
|
|
share the keyexpansion component which provides decrypt and encrypt keys (which are
|
402 |
|
|
the same only in opposite order). Each datapath is controlled by its own \FSM\. If
|
403 |
|
|
configured by the generic \texttt{DECRYPTION} \ref{gen:decryption} the decryption
|
404 |
|
|
datapath is included and some multiplexers are generated for the shared signals,
|
405 |
|
|
e.g. \texttt{result} or \texttt{roundkey\_index}.\\
|
406 |
|
|
For reference the encryption data path of \texttt{aes\_core.vhd} is given in figure
|
407 |
|
|
\ref{fig:aescore}. The decryption datapath is left for the reader or any other author
|
408 |
|
|
of this document.
|
409 |
|
|
\begin{figure}[!ht]
|
410 |
|
|
\centering
|
411 |
|
|
\includegraphics[width=0.9\textwidth]{CoreEncDP}
|
412 |
|
|
\caption{Encrypt datapath of the AES core as implemented in aes\_core.vhd}
|
413 |
|
|
\label{fig:aescore}
|
414 |
|
|
\end{figure}
|
415 |
|
|
|
416 |
|
|
|
417 |
|
|
\newpage
|
418 |
|
|
\section{License and Liability}
|
419 |
|
|
\label{sec:license}
|
420 |
|
|
The ``AES 128/192/256 (ECB) Avalon\rtm-MM Slave'' component, all its subcomponents
|
421 |
|
|
and documentation (like this document you are reading) are published under following
|
422 |
|
|
license:\\
|
423 |
|
|
|
424 |
|
|
Copyright (c) 2009, Thomas Ruschival - All rights reserved.
|
425 |
|
|
|
426 |
|
|
Redistribution and use in source and binary forms, with or without modification, are
|
427 |
|
|
permitted provided that the following conditions are met:
|
428 |
|
|
\begin{itemize}
|
429 |
|
|
\item Redistributions of source code must retain the above copyright notice, this
|
430 |
|
|
list of conditions and the following disclaimer.
|
431 |
|
|
\item Redistributions in binary form must reproduce the above copyright notice, this
|
432 |
|
|
list of conditions and the following disclaimer in the documentation and/or other
|
433 |
|
|
materials provided with the distribution.
|
434 |
|
|
\item Neither the name of the organization nor the names of its contributors may be
|
435 |
|
|
used to endorse or promote products derived from this software without specific
|
436 |
|
|
prior written permission.
|
437 |
|
|
\end{itemize}
|
438 |
|
|
THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
|
439 |
|
|
AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
|
440 |
|
|
IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
|
441 |
|
|
ARE DISCLAIMED. \\
|
442 |
|
|
IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE
|
443 |
|
|
LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY,
|
444 |
|
|
OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
|
445 |
|
|
SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
|
446 |
|
|
INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
|
447 |
|
|
CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
|
448 |
|
|
ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF
|
449 |
|
|
THE POSSIBILITY OF SUCH DAMAGE\\
|
450 |
|
|
|
451 |
|
|
Note: The term ``SOFTWARE'' in the above licence applies in this case not only to
|
452 |
|
|
software as executable code but also to documentation, hardware description or
|
453 |
|
|
compiled netlists for actual target hardware. As Chips generally don't just
|
454 |
|
|
reproduce ``the above copyright notice, this list of conditions and the following
|
455 |
|
|
disclaimer in the documentation and/or other materials provided with the
|
456 |
|
|
distribution'' the datasheet of the product must also contain it.\\
|
457 |
|
|
|
458 |
|
|
Altera, CycloneII, StratixII and Avalon are registered trademarks of the Altera
|
459 |
|
|
Corporation
|
460 |
|
|
101 Innovation Drive, San Jose CA USA \\
|
461 |
|
|
Xilinx, Spartan3A and Virtex5 are registered trademarks of Xilinx Inc. 2100 Logic Drive, San Jose CA USA \\
|
462 |
|
|
Mentor Graphics and ModelSim are registered trademarks of Mentor Graphics
|
463 |
|
|
Corporation 8005 SW Boeckman Road, Wilsonville OR USA \newpage
|
464 |
|
|
|
465 |
|
|
\printacronym
|
466 |
|
|
\printglossary
|
467 |
|
|
|
468 |
|
|
\bibliography{cited}
|
469 |
|
|
\revisionTable
|
470 |
|
|
|
471 |
|
|
\end{document}
|