app_load.html
7.95 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
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="content-type">
<title>Boot sequence walkthrough</title>
</head>
<body>
<h1>Tutorial walk through app launch sequence in SK</h1>
<br>
This document is meant to describe the steps in validating and
launching the "first app" from the SK. The same procedure has to be
followed to launch any system or common app from the system area. The
implementation has to take care of the lack of file system
support (and the quirks of flash), and security checks while loading an
app with strong authentication.<br>
<br>
Start following in the tree sw/bbplayer/bbapps/sk/entry.s<br>
<ul>
<li>following the title "BOOT ENTRY" label enter_boot, after
zero_bss, it jumps to <span style="font-style: italic;">skEntryBoot.</span></li>
</ul>
Start following sw/bbplayer/bbapps/sk/boot.c<br>
<ul>
<li>follow the function skEntryBoot() upto the statement <br>
</li>
</ul>
if( (ret =
loadSysapp(&loadAddr)) != SK_SUCCESS ){<br>
<br>
this is the functionality to be replicated in any
"app loader". <br>
<ul>
<li>Follow the function loadSysapp(). The first thing that has to be
done is loading the system app ticket and peripheral data structures
(and validate them). The ordering of these data structures in flash is
as follows: SK->Sys_app.tik bundle->System_app. The system app
ticket bundle has the content meta data header (the rest is irrelevant
for a system app)->two certs to help validate the content meta data
header->crl ->certs to validate crl. The order is fixed but the
absolute flash block number is not fixed. It is found by skipping bad
blocks until a good one is found. The entire ticket bundle is one
block. <br>
</li>
<li>Creation of the bundle involves using the system app, the key and
IV as inputs to mkCmd tool. The outputs of these are system_app.tik and
system_app.aes. Then bundlebootapp makes the bundle with the certs and
crls attached. The crl starts at version 1 for this bundle.</li>
<li>Back to the code: <br>
</li>
<li>
<pre>if( (ret = findGoodBlock(*startNandBlock,SK_BLOCKS))<0)<br> return ret;</pre>
the call findGoodBlock() can be used to skip over and find the next
good block. <br>
</li>
<li>The next lines read in page by page, and copy the entire block to
IRAM. This block contains the entire ticket bundle, including
everything needed to validate it. <br>
</li>
<li>The validation starts from checking for any revoked certs. The
certs (in the development environment) are the defaults installed in
$ROOT/usr/host_data. They are automatically used by the tools mkCmd and
bundleBootApp. Locate the start of content meta data header (cmd), the
certs and rlBundle (CRLS+certs) and call</li>
<li>
<pre>if(sysappBundleRevoked(cmd, certs, rlBundle) < 0)...</pre>
</li>
<li>Following this, check the cert chain for the content meta data
itself</li>
<li>
<pre>if(verifyCertChain(certs,CHAIN_TYPE_CONTENT_PUB) < 0)...</pre>
</li>
<li>The next call to verifyRsaSigDataChain validates the content meta
data header itself. <span style="font-style: italic;"></span></li>
<li><span style="font-style: italic;">Note: for validating a cmd
bundle from an app, use the skVerifyHash() call, it does the equivalent
of the three steps above: check CRL, check certs, check sign. Only
difference is that we need to pass in the "hash" of the cnd header. The
SK call ensures that the steps can access internal virage and do the
necessary checks to CRL etc.</span></li>
<li><span style="font-style: italic;"></span>Next line<span
style="font-family: monospace;"></span></li>
<li><span style="font-family: monospace;"></span>ret =
aes_SwDecrypt((u8 *)v2->bootAppKey,<span
style="font-family: monospace;"> </span>(u8 *)cmd->commonCmdIv,
....<br>
<span style="font-family: monospace;"></span></li>
<li><span style="font-family: monospace;"></span>extracts the key
from the header and the hash for decrypting and validating the content
of the system app itself. The extraction itself involves decrypting the
content meta data header. The key for this is the common key in virage.
It is hard coded in the development tools to make virage. The IV is in
the cmd itself, and the relevant portion is decrypted.</li>
<li><span style="font-style: italic;">Note: for validating a cmd
bundle from an app, do not perform this step. The common key in virage
is not accessible from the app and it is not desireable to hard code
it. So instead, skip this step. Following this step, the SK sets up the
key for decrypting the first system app content. That key should be
programmed in the decryption engine. Use the same key to decrypt
further content. Also, this key is not a common key. It is whatever is
in the system app ticket. (For development purpose it is hardcoded in
mkCmd tool).<br>
</span></li>
<li>After this the validation returns and proceeds in loadSysApp to
aesHwInit(). This step programs the key and Iv in the cmd header to
affect the upcoming decryption of the system app. <span
style="font-style: italic;">Note: for further app loading purposes,
skip this step, and use the same key and IV to load</span></li>
<li>The three SHA calls for computing hash (of the sys app content)
are SHA1Reset(), SHA1Input() and SHA1Result. The first call is made to
initialize, followed by multiple calls to SHA1Reset with each chunk of
data, followed by the last call to get the result. The sizeof the
content is in the ticket, and should be used to get the number of
pages. The call <br>
</li>
<li>
<pre> if((ret = processSysappPage(pageNum, piBuf, useHwChaining,</pre>
</li>
<li>processes a page at a time, including the SHA calculation and
decryption. If uses as IV the last block of previous page,
automatically chained in HW.</li>
<li>In the first loop the first 4KB is just loaded to get the dram
address. The next loop does the processing of the remaining pages, now
moving data to the right dram target. The hash is accumulated and
verified with respect to that loaded from the ticket.</li>
<li>The last step is to set access rights as in the content meta data
header, and return to skEntryBoot.</li>
</ul>
<ul>
<li><span style="font-style: italic;">Note: the steps until here
cannot be changed, so the bootstrapped loading of another app has to
assume the ticket and app to be located *after* the first system app
and before the start of file system area. The size, key and hash for
the second app have to be contained in the corresponding ticket, and
the entire (ticket, content) data can be encrypted using the same key
as the first sysapp. The IV will be setup automatically.</span></li>
<li><span style="font-style: italic;">Note: the relevant tools are:
mkCmd and bundleBootApp which require additions to bundle a second app
and ticket.</span></li>
<li><span style="font-style: italic;">Description of cmd
header: </span>caCrlVersion is 0, cpCrlVersion is now at 1. The
size, descFlags (no reencryption etc, see define) have to do with the
content; commonCmdIv is hardcoded, works with the hardcoded key in
virage, the common decryption key for the encrypted portion of this
data structure. The next hash and iv refer to the content (app).
The next fields are the access rights. Set up the minimal rights as
applicable. bbid = 0 (works on any BB). The next is the issuer
for the target app (the signer of this ticket). The id and key fields
are for the decryption of the first app. For the second app these
fields are not used, the key/IV from the hardware are used. The last
field is contentMetaDataSign. It is the signature by the issuer for
this structure. The tool mkCmd automatically creates and inserts this.</li>
</ul>
<br>
<br>
<br>
</body>
</html>