<!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>