first_app_spec.html
8.09 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
159
160
161
162
163
164
165
<html>
<head>
<title>BB System and Manufacturing App Requirements</title>
</head>
<body>
<h1>
<p align="center">
BB System and Manufacturing App Requirements
</p>
</h1>
At system boot, the secure kernel (SK) will load an application based
on it's predefined positioning in external flash (i.e., on the memory
module). This document functionally specifies two such applications.
The first is used during system manufacturing and is referred to as
the manufacturing application (MA). The second is the system
application (SA) that will ship with the player.
<p>
The specifications for these applications depend on assumptions
regarding the manufacturing process flow, so these assumptions are
covered next. Following that, the specifications for the MA and SA
will be provided.
<p>
Some preliminary disclaimers are in order. First, this specification
is not meant to imply a software development structure. The decisions
regarding library APIs and development should be taken up
separately. Second, the actual set of diagnostics that must be run for
player system test and burn-in at the factory are not addressed
here. The goal for this document is to address the role of the DA in
setting up the player for it's first usage once it leaves the
factory. This is important because various responsibilities must be
shifted between the DA and SA before content can actually be run.
<h2>Manufacturing Assumptions</h2>
As part of the memory module (contains the external nand flash)
burn-in, the following will be performed before it is inserted into a
player:
<ul>
<li> SM physical format for the block status byte in every page
<li> SK written in first 64KB worth of good blocks
<li> MA and MA license/eTicket (MAL) written in accordance with
flash layout (pending FS finalization, but MA and associated
MAL likely follow SK in next good blocks)
</ul>
Content is assumed not to be written to flash for reasons indicated
later.
<p>
During system manufacturing, the system diagnostics and burn-in are
run after the memory module is plugged in and power is applied. This
first level of diagnostic is run without external connection of
interfaces such as video, audio or USB. The MA is responsible for
running these diagnostics. Once these diagnostics successfully
complete the player will be connected to a manufacturing PC via USB
(power may or may not have been cycled).
<p>
The USB connection will be used so the MA can proceed to replace
itself on the module with the SA and load and personalize content. The
manufacturing PC will have access to the appropriate content keys for
the connected player, and the DA will perform an on-the-fly
re-encryption so this step does not need to occur when the user first
attempts to use the content.
<h2>Manufacturing Application Specification</h2>
Given the above manufacturing assumptions, the MA must perform the following:
<ul>
<li> determine the manufacturing process phase based on USB connection.
If no USB run test/burn-in. Otherwise, proceed with tasks to be
carried out while connected to manufacturing PC.
<li> run burn-in diagnostics, indicate pass-fail via LED
<li> initialize the filesystem data structures and write to flash
<li> make USB connection to manufacturing PC as slave
<li> USB driver and protocol implementation (slave mode) for indication
of actions to take (master will dictate steps, which drive bullets to
follow)
<li> download SA and SAL, replacing the MA/MAL flash images with these
<li> download content, which requires
<ul>
<li> allocate flash blocks for content to satisfy ATB constraints
<li> re-encrypt on the fly as content is stored to these blocks (SK
calls are used to accomplish this). Note that this
re-encryption is not required to be robust to power off,
however the SA version will.
</ul>
<li> manage re-encryption key table storage for SK
</ul>
<h2>System Application Specification</h2>
The SA is not assumed to require any USB connectivity initially. This and
other items that have been considered in the past and are not required in
the initial SA version will be listed as "NO" items in the following list.
<ul>
<li> Content browsing UI: present an interface to the user that allows
choice of playable content to launch. The non-UI component primarily
involves license parsing to obtain meta-data content descriptions.
The SA application development framework is not intended to be
generic, so providing a generic framework for general app development
is not a requirement for the SA.
<li> Launch an application: once content is chosen, arrange for launch.
This includes setting up ATB for flash layout, initializing "state",
calling SK API to validate and launch (this step may include CRL
steps).
<li> State management: each content may have multiple associated state
files (user profiles is a loose analogy). Before content is launched
the proper profile must be chosen. The same applies to storage?
When a game is exited, the SA will be launched to save state which
changed during play.
<li> Entrance API: present an entrance API that indicates what action
should be taken. On initial player startup the SA presents SA to
launch content. After game and before powerdown, just save state
and power-off. Others?
<li> In-place, robust, content re-encryption: content is loaded to flash
at the depot in a manner suiting ATB constraints (possibly with extra
block(s) to allow robust in-place re-encryption). The SA will re-encrypt
before first play, using the same flash layout for the result. A number
of SK API calls will be made, and this must be done such power-off does
not fatally impact this process (must be able to re-start at ensuing
power up before game is played, and not require another depot trip).
<li> manage re-encryption key table storage for SK
<li> FS layout satisfying ATB alignment constraints: although this is
initially performed by MA or depot when content is originally loaded, if
a block goes bad during re-encryption a new layout will need to be
found. For a small risk we could eliminate this initially.
<li> CRL management ???: need to check if writing updates to CRL data on
flash (for SK) is required in final CRL scheme.
<li> FS Maintanence: this list may grow, but initially we should at least
periodically check the area of module flash holding the bbid and
rewrite if necessary (single-bit error is present). This is required
because loss of this data would have catastrophic result when the
bbid card is brought to the depot, since eTickets could not be loaded.
The probability of this error is low, so we could decide against this
without great risk.
<li> Real-time Clock Management: (need more clarity on requirements here)
<li> NO eTicket storage management (ability to write in robust manner)
other than the ability to read from FS.
<li> NO content "clean-up" before going to depot: this may be useful later,
but is unlikely to be used in an initial release. That is, if the user
has never been to the depot the would not be expected to perform proper
preparation before going (making room for new content). Also, the depot
will need a mechanism for doing this anyway. Since there is an
opportunity to provide a new version of the SA at every depot trip,
the users first trip could result in a SA update with this feature if
we later decide it is prudent.
<li> NO slave mode (???).
<li> NO usb driver or protocols (may come with subsequent SA updates).
<li> NO partition to allow non-depot self update: if we want to update
over USB or modem, the SA should be partitioned to allow for this
in a robust manner. Since the initial updates will only occur at
the depot this is not required. If in the future this requirement
does arise, or the SA grows too large, a depot trip can be utilized
to update to a version satisfying this requirement.
</ul>
</body>