1<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
2<!--==========================================================================
3  Copyright 2006 Nintendo.  All rights reserved.
4
5  These coded instructions, statements, and computer programs contain
6  proprietary information of Nintendo of America Inc. and/or Nintendo
7  Company Ltd., and are protected by Federal copyright law.  They may
8  not be disclosed to third parties or copied or duplicated in any form,
9  in whole or in part, without the prior written consent of Nintendo.
10 ==========================================================================-->
11<HTML>
12<HEAD>
13	<META http-equiv="Content-Type" content="text/html; charset=windows-1252">
14	<META name="GENERATOR" content="IBM WebSphere Studio Homepage Builder Version 7.0.0.0 for Windows">
15	<META http-equiv="Content-Style-Type" content="text/css">
16	<TITLE>Digital Signatures &mdash; Overview</TITLE>
17	<LINK rel="stylesheet" href="../../css/nitro.css" type="text/css">
18</HEAD>
19<BODY>
20<H1 align="left">Digital Signatures &mdash; Overview</H1>
21<H2>Description</H2>
22<H3>What Is a Digital Signature?</H3>
23<P>
24	A digital signature is a mechanism that is used to verify the authenticity of data that has been received via an untrusted route such as the Internet.
25</P>
26<BLOCKQUOTE><IMG src="image_Signature.gif" border="0"></BLOCKQUOTE>
27<ul>
28	<li>The signing party (the developer) and the verifying party (the user's Nintendo DS system) participate as working subjects.</li>
29	<li>The data involved consists of the private key, public key, send data, and digital signature for the send data.</li>
30	<li>The private key is a secret known only to the signing party.</li>
31	<li>A public key must be obtained ahead of time by the verifying party using some reliable means (such as having it burned onto the game card).</li>
32	<li>The send data is a binary file of any size.</li>
33</ul>
34<ol>
35	<li>The signer uses the private key to create a digital signature having a fixed length from the send data.<BR>(Actually, a hash value for the send data is obtained and operations are performed on that.))</li>
36	<li>The verifying party receives the send data and the digital signature for that data via the Internet or other means.</li>
37	<li>The verifying party then uses the previously obtained public key to authenticate the data based on the send data and the signature.</li>
38</ol>
39<P>
40	Digital signatures have the following features.
41</P>
42<ul>
43	<li>As long as the verifying party has the public key ahead of time, he or she can determine authenticity with only the data and the signature associated with it without any further external communications.</li>
44	<li>As long as the private key is not leaked, a signature cannot be forged even if the public key is known.<BR>(In other words, signatures cannot be forged even if the ROM binary on the DS is somehow analyzed.)</li>
45</ul>
46
47<H3>Digital Signature Features Provided by the CRYPTO Library</H3>
48<P>
49	In addition to the NITRO CRYPTO features for verifying digital signatures, the TWL-SDK CRYPTO library adds features for creating digital signatures.
50</P>
51<P>
52	We provide the <A href="../sign/CRYPTO_VerifySignature.html"><CODE>CRYPTO_VerifySignature</CODE></A> and <A href="../sign/CRYPTO_VerifySignatureWithHash.html"><CODE>CRYPTO_VerifySignatureWithHash</CODE></A> functions for use in verifying digital signatures. We do not provide a feature for managing the expiration dates of the certificates. If necessary, implement this in the application.
53</P>
54<P>
55	We provide the <A href="../rsa/CRYPTO_RSA_Sign.html"><CODE>CRYPTO_RSA_Sign</CODE></A> function for creating digital signatures. This function is special in that it will not be processed even if it is run. Before running this function, you must initialize it using the <A href="../rsa/CRYPTO_RSA_SignInit.html"><CODE>CRYPTO_RSA_SignInit</CODE></A> function; after you have created the signature, you must also shut it down using the <A href="../rsa/CRYPTO_RSA_SignTerminate.html"><CODE>CRYPTO_RSA_SignTerminate</CODE></A> function.
56</P>
57
58<P>
59	A digital signature only verifies the legitimacy of the data. Data encryption is not performed.<BR>The CRYPTO library provides three cryptographic algorithms: (1) RC4, which is fast but weaker in terms of its encryption strength, (2) AES, a shared-key cryptography algorithm that provides stronger encryption, and (3) RSA, a public-key cryptography algorithm that is advantageous in terms of key distribution. Refer to <A href="about_RC4.html">RC4 Algorithm Overview</A> for more about RC2 and <A href="about_RSA.html">RSA Algorithm Overview</A> for more about RSA.<BR>We have also prepared AES encryption functionality for TWL-SDK, which uses hardware features. For details, see the items about AES.
60</P>
61
62<P>
63	Although the digital signature verification feature works for NITRO and TWL, due to licensing issues, the digital signature creation feature works only on TWL.
64</P>
65
66<H3>Signature Data Format</H3>
67<P>
68	Signature data passed to the <code>CRYPTO_VerifySignature*</code> functions can be created using any method as long as it satisfies the following conditions. (It goes without saying that you can also use signature data that was created with the <A href="../rsa/CRYPTO_RSA_Sign.html"><CODE>CRYPTO_RSA_Sign</CODE></A> function.)
69</P>
70<ul>
71	<li>The data format for keys conforms to ASN.1 format and is DER encoded</li>
72	<li>It uses SHA-1 as the hash algorithm</li>
73	<li>It uses RSA for the public key encryption algorithm with a key length of 1024 bits</li>
74	<li>The public exponent of the public key is 65537</li>
75</ul>
76
77<H3>Examples of Creating Signature Data</H3>
78<P>
79	The following is an example of the procedure for generating a digital signature with OpenSSL from the open source SSL tool kit.
80</P>
81
82<P><B>1. Generate an RSA Key for the Signature</B></P>
83<P>
84	Type the following command in the command-line interface of the OpenSSL environment to generate <CODE>privkey.pem</CODE>, a 1024-bit RSA key file.
85</P>
86<PRE><CODE> &gt; openssl genrsa -out privkey.pem 1024</CODE></PRE>
87<P>
88	If this file were leaked, anyone would be able to sign data with it. The private key file therefore needs to be maintained with the strictest care.
89</P>
90<P>
91	Password-based encryption for <CODE>privkey.pem</CODE> is possible by specifying the encryption method when generating the key. In the following example, a newly generated <CODE>privkey.pem</CODE> file is encrypted with the 3DES algorithm.
92</P>
93<PRE><CODE> &gt; openssl genrsa -des3 -out privkey.pem 1024</CODE></PRE>
94<P>
95	For more information, see the <CODE>openssl</CODE> reference.
96</P>
97
98<P><B>2. Confirm the Content of the RSA Key</B></P>
99
100<P>
101	Use the following command to confirm the content of <CODE>privkey.pem</CODE>.
102</P>
103
104<PRE><CODE> &gt; openssl rsa -in privkey.pem -text -noout</CODE></PRE>
105
106<P>
107	The output includes the private information needed for signing and two additional public key values needed for verification: modulus and publicExponent.<BR>The following is an example of extracted <CODE>modulus</CODE> and <CODE>publicExponent</CODE> values output from the command.
108</P>
109
110<PRE><CODE>
111modulus:
11200:eb:95:be:33:19:73:64:f2:72:2c:87:c8:0a:f3:
1131c:ba:e0:4c:e0:3e:1d:f6:e2:09:aa:70:f0:b3:b9:
1140c:86:36:62:2d:12:13:86:fa:a5:3d:93:cb:5f:0b:
11545:64:9b:7b:eb:b5:c6:f9:42:99:70:46:f3:14:6d:
1168f:f9:b9:ec:38:30:a0:1c:28:0d:30:d9:86:1a:4d:
1171b:f2:e9:05:1b:43:06:b2:c0:55:ed:c4:bb:8e:1a:
118a5:ab:2b:54:e5:dc:8d:70:cf:af:91:94:c9:e9:8f:
1197f:9f:29:28:be:e7:01:b0:20:d4:f2:71:58:93:db:
12025:1c:26:bc:98:f3:a2:b3:47
121publicExponent: 65537 (0x10001)
122</CODE></PRE>
123
124<P>
125	The public exponent used by the <code>CRYPTO_VerifySignature*</code> function is 65537. Confirm that <CODE>publicExponent</CODE> has a value of 65537.
126</P>
127
128<P>
129	The modulus value can also be generated with the following command.
130</P>
131
132<PRE><CODE> &gt; openssl rsa -in privkey.pem -modulus -noout</CODE></PRE>
133
134<P>
135	This command outputs a text string similar to the following.
136</P>
137
138<PRE><CODE> Modulus=EB95BE33197364F2722C87C80AF31CBAE04CE03E1DF6E209AA70F0B3B90C8636622D121386FAA53D93CB5F0B45649B7BEBB5C6F942997046F3146D8FF9B9EC3830A01C280D30D9861A4D1BF2E9051B4306B2C055EDC4BB8E1AA5AB2B54E5DC8D70CFAF9194C9E98F7F9F2928BEE701B020D4F2715893DB251C26BC98F3A2B347</CODE></PRE>
139
140<P>
141	The hexadecimal value following <CODE>Modulus=</CODE> must be converted to a <CODE>u8</CODE> array in C and passed as <CODE>mod_ptr</CODE> to the <code>CRYPTO_VerifySignature*</code> functions. In the previous example, the modulus is 127 bytes in length because the leading zeros are omitted when the length is less than 128 bytes. When passing the value to <CODE>mod_ptr</CODE>, be sure to restore any leading zeros to maintain a length of 128 bytes.
142</P>
143
144<P><B>3. Generate a Digital Signature</B></P>
145
146<P>
147	Once the above steps are complete, simply create a digital signature for the target data.<BR>With TWL, the digital signature can be created using the <A href="../rsa/CRYPTO_RSA_Sign.html"><CODE>CRYPTO_RSA_Sign</CODE></A> function. It can also be created on a computer.<BR>The following command uses the <CODE>privkey.pem</CODE> private key to generate signed data (<CODE>hoge.sign</CODE>) from the unencrypted data (<CODE>hoge.txt</CODE>).
148</P>
149
150<PRE><CODE> &gt; openssl dgst -sha1 -sign privkey.pem -out hoge.sign hoge.txt</CODE></PRE>
151
152<P>
153	Confirm that the resulting file size is 128 bytes.<BR>This 128-byte binary data is transferred to a DS and passed to the <code>CRYPTO_VerifySignature*</code> function as <SPAN class="argument">sign_ptr</SPAN>.<BR>Run the following command to confirm on the computer whether the generated signed data forms a valid digital signature.
154</P>
155
156<PRE><CODE> &gt; openssl dgst -sha1 -prverify privkey.pem -signature hoge.sign hoge.txt</CODE></PRE>
157
158<P><B>4. Verifying Digital Signatures</B></P>
159
160<P>
161	By embedding public key data in a DS program in advance, it can then receive data and digital signature data. To verify a digital signature, the <code>CRYPTO_VerifySignature*</code> functions require the data and the data size, the digital signature data (128 bytes), and the embedded public-key data (the 128-byte modulus). The return value is <CODE>TRUE</CODE> if the data is determined to be valid.
162</P>
163<P>
164<H2>See Also</H2>
165<P><A href="../list_crypto.html#sign">List of CRYPTO Functions</A></P>
166<H2>Revision History</H2>
167<P>
1682008/10/02 Revised the key format.<BR> 2008/09/16 Revised some comments.<BR> 2008/04/18 Added support for the addition of a electronic signature creation function.<BR> 2008/03/27 Initial TWL-SDK migration version.<BR> 2006/03/07 Initial version (NITRO CRYPTO).
169</P>
170<hr><p>CONFIDENTIAL</p></body>
171</HTML>
172