limited_rights.html
12.6 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
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<title></title>
</head>
<body>
<h2>Limited Rights</h2>
27th June 2003<br>
David Blythe<br>
<br>
We would like to have mechanisms to support the following scenarios:<br>
<br>
<blockquote><i>1. Time-Limited and Play-Limited Rights (Rental, Trials)</i><br>
The licensing information for a peice of content indicates the duration for
which it can be played. The content can be purchased multiple times,
and the rights should be aggregatable. The player-side scope of this
is limited to enforcing that rights in a secure fashion. The content
and rights are BBCard independent, meaning that the content and rights can
be moved to another card.<br>
<br>
<i>2. Trading Content (Transfer of Rights)</i><br>
An end user can give up the rights to a piece of content and transfer them
back to the server. The user can sell the transfered rights to another
player. The player-side of this is limited to securely revoking the
rights for a particular ticket or set of tickets.<br>
<br>
<i>3. Bonus Content (Result of Playing Game A Grants Rights to Play B)</i><br>
As a result of playing a piece of content, additional rights to play another
piece of content are created. The rights for the new content are a
function of the vector of all saved state on a BBCard. The player side
of this is limited to computing the new rights from the saved content state
vector and securely enforcing the new rights.<br>
</blockquote>
<h3>Assumptions</h3>
<ol>
<li>Number of pieces of content for a particular player running
in a limited-rights mode can be small (e.g., 4 <= n < 10). This allows
the rights information to be securely stored in player-resident non-volatile
memory and avoids a complicated scheme for handling multiple BBCards.</li>
<li>If the user exceeds or is about to exceed #1 they can be warned
at either at the depot or on the player. At the depot, they can cancel
the purchase, on the player they can defer play until they have consumed
another piece of content completely, or they can mark a rights-limited content
as consumed.</li>
<li>Some small security leakage is acceptable. For example, a user
may be able to circumvent security enough to steal a piece of content that
they have paid for at least once (for example in the trading example).</li>
<li>There is a mechanism to authenticate saved content state.</li>
<li>Time-Limited/Play-Limited and Bonus Game Rights cannot be traded.<br>
</li>
</ol>
<h3>Terminology</h3>
TID - a player-specific ticket id<br>
Limited Rights Content (LRC) - content that has limited rights associated
with it<br>
Limited Rights Ticket (LRT) - a ticket with limited rights rules<br>
Open LR-Ticket - limited-rights ticket that has been "launched" at least
once.<br>
Expired LR-Ticket - limited rights ticket that has been "used up"<br>
CC - consumption counter. An n-bit up counter indicating how much of
the rights of a LRT have been consumed.<br>
CCL - contiguous list of consumption counter values<br>
<br>
<h3>Mechanisms</h3>
<h4>Consumption Counter List</h4>
The basic mechanism is to store a <TID, consumed> association in the
player's not volatile storage. The list indicates the current consumption
state of all LR-Content that has been Opened by the player. It
is desirable to keep the TID and CC as small as possible since there is a
very small amount of storage in the player. Many of the details of
these values arises from this constraint. The TID is a 16-bit unsigned
monotonically increasing counter maintained independently <b>for each player</b>.
The TID counter must be maintained as part of server state for each
player. The CC is a 16-bit monotonically increasing counter.<br>
<br>
The player maintains the consumption list as a sliding window where old LR-ticket
state is garbage collected to make space available for new LR-tickets. A
single cursor is stored indicating the TID base for the current window. If
the non-volatile player memory can hold N entries, then the window of possibly
valid TIDs is <CURSOR+0 .. CURSOR+N-1>. TIDs less than the current
cursor value are invalid or expired. Only the CC values and the cursor
are stored in non-volatile memory. Garbage collection is triggered
whenever a new TID is opened. If the window does not contain the TID,
then the start of the window is scanned looking for expired or unused entries
that would allow the cursor to be advanced. If the cursor cannot be
advanced, the system app is informed and the player is warned. The
system app can force garbage collection. The garbage collection algorithm
may garbage collect a portion of the window for which the user has a valid
but unOpened TID. The player can determine this in advance and warn
the user before the cursor is advanced.<br>
<br>
<h4>LR-Bundle</h4>
The LR-Bundle is part of the ticket associated with content. For simple
time/play limited rights restrictions, the LR-Bundle indicates a code indicating
the consumption algorithm, the consumption granularity, and the consumption
limit value. Two algorithm codes are current supported:<br>
<blockquote>
<ol>
<li>Time Limited: consumption granularity is 1 minute, consumption limit
is in minutes</li>
<li>Number of Plays: consumption granularity is 1 play, consumption limit
is play count</li>
</ol>
</blockquote>
Enforcement of Simple LR-constraints is performed completely in the SK. The
LR-Bundle is presented as part of the application launching sequence. If
the TID is unopened, the Launch sequence attempts to Open the TID. If
the TID is already opened the launch sequence compares the CC against the
limit in the LR-bundle and succeeds or fails accordingly. For time-limited
constraints, the CC is marked as fully consumed during content play and credited
with the balance when the content is exited.<br>
<br>
For Bonus Games, a Computed LR-Bundle is also stored as part of the ticket.
The LR-Bundle contains a Code and granularity, but rather than a static
consumption limit, the code indicates an algorithm for computing the consumption
limit from a set of authenticated content saved states. The computation
of the consumption limit is performed in the sysapp rather than the SK. It
inventories all saved state on the BBCard and computes the consumption limit.
The computed consumption limit and the LR-Bundle is passed to the SK
for validation during launch. <br>
<h4>Access To CC List</h4>
To simplify interactions between the sysapp and SK, the sysapp can query
the contents of the CC List. This query returns a list of <TID,
CC> pairs. Using this information, the sysapp can determine whether
the TID window needs to be advanced to Open a new TID and negotiate with
the user appropriately. The SK also provides a Close operation that
can be used to Close the lowest numbered TID and advance the window by one.<br>
<h3>Corner Cases & Extensions</h3>
<h4>BBCard Is Lost</h4>
The server can reissue tickets with the same TIDs. This implies that
the TID associated with each purchase is stored in the server. The player
could cache the current CCL cursor on the BBCard to avoid reissuing tickets
for TIDs that are no longer valid, but this is an optimization.<br>
<h4>Aggregation</h4>
Ideally it should be possible to purchase additional plays for LR-content
and have them aggregate with existing plays. This can be accomplished
by presenting the LR-Bundles for all unexpired tickets for the same content
id at launch time. The SK must then correctly update the CC for each
of the TIDs when the content exits. In the worst case the SK must maintain
a list of consumption limits the size of the TID window rather than a single
consumption limit. At content exit, the consumpution value is distributed
over multple CC entries based on the set of stored limits.<br>
<h4>Split CC-lists</h4>
The Simple LR-Bundle and the Computed LR-Bundle share the same CC list in
non-volatile memory. One issue that may arise is that the garbage collection
algorithm may require invalidation of Open Bonus Content TIDs. This
would require periodically reissuing tickets for Bonus Content to ensure
that it has a TID within the current window. An alternative is to maintain
separate sliding windows for Bonus Content and for Time/Play Content. This
partitions the set of Open TIDs into two groups and allows their windows
to progress at different rates. Whether this is worthwhile depends
on the anticipated usage model. If the Limited Time/Play model is popular
than the constantly moving window may make it difficult to keep the TIDs
associated with Bonus Content valid. The server can opportunistically
issue tickets with new TIDs, but it must also revoke the old TIDs, requiring
yet another revocation list.<br>
<h4>Revocations</h4>
Schemes in which tickets are invalidate by revocations can cause problems
with the TID-based scheme. If tickets must be re-issued with new servers,
then either the TIDs must be preserved, or else the tickets will have new
TIDs and effectively reset the accumulated consumption counters. Probably
not a big deal either way.<br>
<h3>Limitations</h3>
The 16-bit CC size allows a window of approximately 24 TIDs. Therefore
there can be at most 24 Open TIDS. The 16-bit CC allows a single LR-Bundle
to support 65530 minutes of play. The use of a 16-bit TID means that
65536 Tickets can be issued to a single player.<br>
<h3>Trading Content</h3>
To securely trade content, all tickets associated with particular content
id must be revoked. Our standard scheme for robust revocation of large
lists of items is to store the revocation list on the BBCard and a version
number in the player non-volatile memory. <br>
This revocation could happen at the depot as part of the trading operation,
or it could happen on the player at home. Revocation is somewhat problematic
in the presence of multiple BBCards since creating a new revocation list
on one BBCard means that the other BBCards will be out of date and it is
awkward to use the player to maintain the ticket revocation list on multiple
cards. To prevent rollback attacks, the revocation should involve
the player to ensure the user doesn't continue operating with an older revocation
list. This is similar to the other revocation lists, if we assume that users
will eventually buy new content then the time window for which the old ticket
will work will be small, so revoking within the player is not completely
necessary.<br>
<br>
Regardless of the exact revocation mechanism, to complete the trading operation
the user must bring the BBCard to a depot (or make a server connection) and
trigger a 2nd-hand sale (buy-back) on the server. The server revokes
the TID, issuing an updated ticket revocation list and stores additional
state on the server to indicate the status of the content.<br>
<br>
Another user can buy the content in a separate, indepedendent transaction.
The original user can also re-purchase the content at a later date
with no loss of generality. It is possible to use a content-id based
revocation list rather than a ticket-id list, but this seems awkward in the
presence of re-purchase since the revoked-id would need to be un-revoked.
<br>
<br>
The only change required on the player is support for the revocation list.
<br>
<h4>Simplifications</h4>
A simpler honor-based scheme simply involves deleting the ticket from the
BBCard rather than adding to a revocation list. This has the advantage
that it leaves the other cards unaffected, in that they do not require synchronizing
the revocation list. A disadvantage is that if the user keeps a copy
of the ticket on another BBCard they can continue to play the content as
long as the ticket is valid. The server must still keep track of revoked
tickets so that it does not reissue them. This scheme also has the
advantage that it requires no player changes to support it.<br>
<h4>Transitive and Transient Trades</h4>
This scheme is fairly heavyweight as a way to lend games to friends and then
get them back since it involves buy-back and purchase. It is unclear
whether there is any way this can be stream-lined (it is mostly a user interface
issue and not a mechanism problem). I the simplest scheme the buy -back
and purchase events are only tracked on the server and there is no information
inside the ticket or on the player indicating the previous history of a ticket
or piece of content. <br>
</body>
</html>