sa.html
4.7 KB
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
<html>
<head>
<meta http-equiv="Content-Language" content="en-us">
<meta name="GENERATOR" content="Microsoft FrontPage 5.0">
<meta name="ProgId" content="FrontPage.Editor.Document">
<meta http-equiv="Content-Type" content="text/html; charset=windows-1252">
<title>Self Update</title>
</head>
<body>
<p align="center"><b>Self Update-able SA Support for
Depot@Home</b></p>
<p>This document describes the changes we need to make to the SKSA area, the
system app itself, and the related packaging/publishing tools in order to
support the self updatable feature required by
Depot@Home</font></a>. </p>
<p>SA will be split into two parts SA1 and SA2. SA1 is booted from SK and is
responsible for booting SA2 when usb cable is not connected; when usb cable is
connected, it is responsible for responding to requests from
Depot@Home app and for blanking the video output. SA2 is the current
viewer app (gzipped to save space). It will be booted by SA1 in the similar way
SA1 is booted by SK. Below is the new layout for the 1M SKSA area on the flash
card, with T1 being the ticket bundle for SA1 and T2 being the ticket for SA2.
The updatable part is the T2+SA2 area. </p>
<table border="1" cellpadding="0" cellspacing="0" style="border-collapse: collapse" bordercolor="#111111" width="100%" id="AutoNumber1">
<tr>
<td width="100%" colspan="5">
<p align="center">SKSA: 64 blocks with 4 bad blocks max</td>
</tr>
<tr>
<td width="12%" align="center">SK</td>
<td width="35%" align="center">
<p style="margin-top: 0; margin-bottom: 0">T1 </p>
<p style="margin-top: 0; margin-bottom: 0">(size1, hash1, commonCmdIv, </p>
<p style="margin-top: 0; margin-bottom: 0">key1, iv1...)</td>
<td width="13%" align="center">SA1</td>
<td width="20%" align="center">
<p style="margin-top: 0; margin-bottom: 0">T2</p>
<p style="margin-top: 0; margin-bottom: 0">(size2, hash2...)</td>
<td width="20%" align="center">SA2</td>
</tr>
<tr>
<td width="12%" align="center">4 blocks</td>
<td width="35%" align="center">1 block</td>
<td width="13%" align="center">n1 blocks</td>
<td width="20%" align="center">1 block</td>
<td width="20%" align="center">n2 blocks</td>
</tr>
</table>
<p>SA1's packaging and boot sequence remains the same as the current
implementation (on the client side, bundleBootApp/mkCmd is used to generate t1
and sa1.aes). T1 contains size1(size of SA1), hash1(hash of SA1), iv1 and
key1(encrypted key by the root key in virage, used to encrypt SA1), and the
commonCmdIv needed when SK decrypts key1. The boot code for SA1 is documented in
detail <a href="../security/app_load.html">here</a>.</p>
<p>SA2's packaging is a little different. We will use the same key (key1) to
encrypt both T2 and SA2, thus the key and iv fields of T2 is ignored. When SK
launches SA1, it software decrypts key1 and sets up the hardware decryption
engine to use the decrypted key1 to decrypt SA1. The assumption is that when SA1
is ready to decrypt SA2, the aes decryption engine still holds key1 and the iv
needed to continue decrypting T2 and SA2, provided that we do not make any
aesHwInit() calls in between. </p>
<p>SA2's boot sequence at a high level: </p>
<ol>
<li>decrypt T2 using the hw decryption engine, use skVerifyHash to validate
T2, get size2 and hash2</li>
<li>continue decrypting SA2 using the hw decryption engine, verify SA2 against
hash2, gunzip SA2</li>
<li>set the rights as specified in T2 for SA2</li>
<li>load SA2 to the correct address and jump to that address</li>
</ol>
<p>SA2's packaging at a high level:</p>
<ol>
<li>gzip sa2.rom, get size2; compute hash on sa2.rom.gz to get hash2</li>
<li>use size2, hash2, the additional params (cert, crls, rights) to generate
an opaque ticket t2 for SA2 (key, iv, and cmdAesIv fields are ignored).</li>
<li>aes_encode "sa1.rom+t2+sa2.rom.gz" using key1 to get sa.aes</li>
<li>slice sa.aes to get sa2.tik and sa2.aes</li>
</ol>
<p>We will provide the raw roms sa1.rom, sa2.rom.gz, and sa.prop file (assuming
sa1 and sa2 has the same rights) for server team to do packaging using their own
set of tools. For development, we use bundleBootApp to generate sa1.tik
and sa1.aes as before, and we need to have a slightly different bundleBootApp2
as described above to generate sa2.tik and sa2.aes. </p>
<p><u>To do list on the client side</u>:</p>
<ol>
<li>SA1</li>
<li>libbbc support for updating T2+SA2</li>
<li>Tools:</li>
</ol>
<ul>
<li>bundleBootApp2 for generating sa2.tik and sa2.aes</li>
<li>additional commands in shell/emsh for updating sa2.tik and sa2.aes on a
flash card</li>
</ul>
</body>
</html>