解决DRM 部署所面临的障碍

数字媒体播放器 OEM 厂商在考虑是否支持 DRM 这一争议性问题之前，要首先了解高效实施 DRM 技术所面临的障碍。高效 DRM 实施技术不仅限于优化的加密库，要是采用错误的实施方法，就会导致商业决策失误，甚至实施失败。本文将深入探讨如何减小 DRM 对数字媒体播放器的影响，以帮助那些希望采用 DRM 技术的 OEM 厂商避免对技术产生恐慌和不确定性情绪，减少对 DRM 实施可行性的不确定因素，从而使他们能专心致力于 DRM 的高效实施问题。本文探讨的方案能解决 DRM 实施所面临的最常见障碍，适用于任何标准或架构。

通常说来，解决 DRM 时延与性能问题的关键在于尽可能减少 DRM 处理任务对关键路径的影响。DRM 处理任务的计划安排通常是实现上述目的的关键，我们可以采用预取 (prefetching) 或预处理数据、后台处理等方案，也可以在用户做思考决定、时延影响不大时进行处理。工程师应侧重于解决以下三个问题，一是启动期间，二是播放，三是内容传输，这三个阶段均会对性能、易用性以及电池使用寿命造成影响。

启动时间
DRM 会影响启动时间，这一点相当重要，起初我们可能还难以直观地察觉到。说到底，DRM 是一种验证使用权限的技术方法，因此就算人们会问，它怎么会影响设备启动时间呢，也不足为奇。要了解这一点，我们就要考虑在任何 DRM 规范中都非常重要的一部分要求，那就是稳健性与符合性认证规则 (R&CR)。

R&CR 是定义着 OEM 厂商如何避免 DRM 软、硬件被欺骗或修改的指南。请注意，尽管这些指南根据具体 DRM 标准的不同可能采用不同的名称，但它们的基本目的都是一样的，即稳健的设备必须能够识别企图改变应用代码的行为，避免 DRM 机制被破解或失效。在对受保护的内容进行解锁或允许存取之前，设备必须先确认 DRM 机制已经就绪，没有被篡改，而且能正常工作。此外，设备必须避免调试工具的使用，因为这些工具会让黑客有机会破解或更改许可证。

R&CR 要求根据特定的系统资产或组件的不同要求采用不同层次的保护机制。举例来说，在基于证书的 DRM 方案中，确认播放器能够播放内容服务器内容的证书就是一种高级资产，要求最高级别的保护，因为证书受损就会导致设备上的所有内容失去保护。如果特定设备的证书由具体 OEM 厂商的证书生成，那么这种证书受损就会导致该 OEM 厂商基于该证书推出的所有设备保护失效。与此相对的是，破译某首歌曲的密钥就不是一种特别重要的资产，因为这种密钥仅保护一项内容。上述资产，不管是证书、密钥还是基于其它一些保护机制或秘密机制，都应得到正确的保护。总体说来，内容受损的风险越大，对稳健性等级的要求就越高，并且对用户使用体验的潜在影响也就越大。

损坏的代码不见得一定是因为恶意攻击而损坏的，但这是对 DRM 构成最危险的威胁之一；如果应用本身就能被修改，那么密钥与内容都可能受损。因此，在执行任何应用代码之前，设备必须确认应用来源的可信赖性。此外，这种验证必须在每次设备加电时进行，这样才能确保硬件没有被篡改。这里要面临的挑战是，确认应用的代码本身也容易受到破坏，因此它也要在执行前进行确认（见图 1）。


图 1. 在加电执行任何应用代码之前，设备必须验证并确认应用来自可信赖的来源。所面临的挑战是，如果验证并确认应用的代码本身也容易受到破坏，那么其也要在被执行前进行验证并确认。但是，如果不能修改 ROM 启动加载程序 (ROM Boot Loader)，那么它就不会受到破坏，因此加电时毋需确认就可以得到信任。




表 1. 安全启动加载程序技术确认设备首次加电启动时软、硬件都处于已知的可信赖状态。为了尽可能降低时延，代码分几个阶段进行验证并载入。如果检测到某个阶段遭到破坏，设备会启动灾难恢复模式并进行设备再配置，如果没有问题，设备就会载入首个代码影像，即 ROM 启动加载程序，这是由硅芯片厂商提供的，不能修改，因此能确保验证有效。将使用散列方法进行后续代码验证，有时还会采用唯一芯片 ID 进行验证，之后进行解密。我们将启动进程分解为几个阶段，这使设备能加速与用户进行互动，缩短了用户所觉察到的启动时延时间。[page]

安全启动加载程序技术是避免执行两难困境的关键，也是成功确认软、硬件均处于已知可信赖状态的关键（见表 1）。当设备首次加电后，处理器会执行已知的 ROM 启动加载程序。这个代码影像是设备专用的，并只支持最基本的功能，其中包括有限的加密功能，以验证并确认后续启动加载程序代码，并在检测到破坏情况下启动灾难恢复模式。该代码不能修改，这一点至关重要；换言之，由于其不能被更改，因此不会遭到损坏，也毋需进行确认。请注意，诸如显示功能等确认故障通知信息等功能可能实现片外存储，或在通过 ROM 启动加载程序确认的代码中有选择性的执行，不过在确认已发生故障的情况下，ROM 启动加载程序不能确保相关代码的可用性。


在许多情况下，ROM 启动加载程序由硅芯片厂商提供，除非双方有特定的协议规定，否则 OEM 厂商不能修改。其首要任务就是确认用户启动加载程序。用户启动加载程序是通过硅芯片厂商开发工具的可配置框架构建而成，由 OEM 厂商确定。它能提供底层驱动程序和连接接口，如显示屏、USB 接口或硬盘等，此外还能补充设备的加密功能。在产品设计阶段，能够根据需要对其进行更新修改，但通常产品上市后就不能再修改了。

ROM 启动加载程序确认用户启动加载程序的常见方法是采用散列来确认代码是否被改动，随后再对代码解密（代码加密是为了避免有可能导致代码安全性受影响或者泄露加密信息的逆向工程破解）。一旦 ROM 启动加载程序验证了用户启动加载程序，用户启动加载程序就可依次验证并确认主应用（即应用启动加载程序），然后用户就能开始存取受保护的内容。如果处理器采用唯一的硅芯片 ID，只可以读取但不能修改，那么代码确认的安全性还能进一步提高。此外，OEM 厂商除了能用这种唯一的 ID 作为密钥根 (root for secret key) 而外，也能用它来对内容加密，使内容锁定于特定的播放器。

如果 ROM 启动加载程序确定用户启动加载程序遭到篡改，那么设备将进入灾难恢复模式。灾难恢复模式是 DRM 的重要组成部分。首先，该设备必须通知用户设备将不能再回放内容（即没有损坏设备，但需要再配置），并解释如何成功地完成设备再配置。不能低估这一步骤的重要性，因为用户一发现设备不能回放内容就会拨打技术支持电话并支付昂贵的费用，用户要是对此不满，甚至会向经销商退货。

此外，设备中存储的密秘机制还会通过其它方式被破坏。举例来说，使用的 DRM 标准会提供一定的机制，以使内容提供商能够“撤销”设备或者 OEM 厂商，或者通过其它方式禁用用户使用受损内容或硬件的权限。通过支持灾难恢复功能，设备内置了用于固件升级的安全机制，这样 OEM 厂商就能用新的安全机制来替换设备上未被禁用的机制。当然，设备必须能够确保任何替换代码影像或加密机制更新都具有值得信赖的来源。

请注意，灾难恢复也许并不是 ROM 启动加载程序的专属职责，但除了启动灾难恢复之外，ROM 启动加载程序的作用有限，比方说其不能通过 USB 下载影像。正是由于此原因，也不应该修改用户启动加载程序，这样才能确保灾难恢复代码不会损坏，从而使设备能从故障中有效恢复。


将启动进程分为若干个阶段有不同的作用。首先，这能让开发人员更方便地对设备专用和应用专用代码进行分组。不过，更重要的是，将启动过程分为若干阶段能减少设备启动过程中用户所能感知的时延。我们不妨设想，确认代码的延迟通常与代码影像的大小成正比（不过并不仅与影像大小有关），代码影像越大，确认所需的时间就越长。应用代码确认时，用户不得不对着空白的、没有响应的屏幕发呆，甚至会怀疑是不是电池没电了。

采用分散式用户启动加载程序并分阶段载入应用使设备能更快地与用户互动。比方说，用户启动加载程序完成后，就会立即在屏幕上显示“醒目”页面，以便让用户总体上感觉到设备的响应要快一些，并确信设备已经开启。甚至应用启动影像本身也可分为不同的阶段。用户界面功能可分阶段载入执行，比方说先载入用户界面代码，再载入数据库，这样用户就能访问列表中可用的内容，用户可以在大部分应用启动加载程序（如现在还不需要的 DRM 功能）不断确认并进行后台载入的同时就开始选择待播放的内容。如果必须同时确认整个应用代码，那么在应用代码确认结束、信息显示在屏幕上之前可能要花上数十秒钟的时间。




硬盘运行

优化加密功能可提高性能，不过，如前所述改善启动时间时延问题的关键在于将启动功能进行良好的计划安排，与其它工作同时进行，这样就能通过后台启动。同样的原理也有助于降低不同操作之间用户所能感知到的延迟，比方说选歌与听歌之间的时延就会感到缩短。最小化延迟对改进总体用户体验至关重要。

图 2a 显示了播放前一般的 DRM 确认内容进程。验证内容与验证代码的不同之处在于，许可证、密钥或散列信息可能没有与受保护的内容存储在一起，而是存储在数据库中。比方说，用户的许可证限制了某首歌曲能被播放的次数，超过这个次数许可证就会过期。这就会增加一系列验证工作的额外步骤，因为用户的播放列表可能很庞大（比方说一个文件夹中的音乐容量就达 20GB），因此我们必须生成支持索引功能的数据库，这样才能实现快速查找。

播放前的内容验证

图 2a 显示了播放之前验证内容的一般 DRM 进程。在本例中，所有 DRM 处理都位于关键路径中，这就会导致时延最大化。

优化数据库搜索要求开发人员在性能、存储器占用以及电池使用寿命之间进行平衡取舍。或许，影响上述因素的最重要考虑就是确定某项操作是否需要对硬盘进行存取。硬盘是便携式媒体播放器最大的耗电因素，甚至比显示屏的耗电量还大。不是所有 PMP 都具有硬盘，不过不使用硬盘的设备其存储空间要小得多，因而其数据库也更小，更易于管理。

节省电量的最佳策略之一就是最大限度地减少硬盘必须加速转动的次数。我们可以将硬盘存取集中在一起，而不是播放三首歌曲就要让硬盘从播放列表中载入三次。系统可以提前预计用户接下来在播放列表中最可能播放的歌曲，并同时载入三首歌曲。如果预计错误（用户选择其它歌曲播放），那么预取其它歌曲所用的电量就会被浪费掉。但是，执行预取所耗的电量相对于硬盘额外转动所耗电量来说非常小，从长远来看还是非常省电的。

上述策略也可应用于数据库检索。根据数据库大小的不同，我们有时可以将数据库整个都存储在存储器中，这样存取数据库就不需要操作硬盘了。在启动时就将数据库存入存储器，其所发生的更改都存入存储器中，隔一段时间才向硬盘传输。通常播放器有 10到 20 MB 的预取缓冲器容量，足够用于 10 到 40 分钟的音频。在缓冲器中存储数据库会减少内容播放所需的存储容量，但这样无需执行硬盘，从而显著缩短了检索时间。请注意，由于存储器中也载入了许可证数据库，因此系统能在执行硬盘前将数首歌的加密功能进行排序，而不是在硬盘转动时进行加密计算，而让写入磁头处于空闲状态。但是，将所有许可证都存于 RAM 中会大幅降低设备的安全可靠性，因此这种做法应当避免。

我们不妨设想这样一种情况，当用户首次启动播放器时，闪屏立即出现，然后出现可用的播放列表。用户考虑先播放哪首歌曲花的时间通常已足够该应用来完成加载任务。如果用户快速选择了播放的歌曲，那么就载入第一首歌的数据及其许可证，并对这些信息进行评估然后开始操作，这样就能最大限度地缩短用户欣赏到音乐所需的时间。

这时，由于设备还没有机会进行预取，所有 DRM 处理都位于主处理路径上。不过，在播放第一首歌时，播放器可将许可证数据库下载至存储器，这样播放器就能为播放列表中接下来的歌曲预先处理许可证密钥，并预取适当的曲目。这样，大多数 DRM 处理任务都能在后台得到高效地计划安排，毫不影响用户的欣赏体验，而且还能尽可能减少对硬盘的存取（见图 2b）。

[page]


数据库的可靠性

根据所采用的 DRM 机制的不同，管理存储器中的数据库比管理硬盘驱动器中的数据库更为复杂，因为我们必须防止能量攻击 (power attack)，至少也要提供适当的保护功能。不妨设想，有的歌曲采用“限次播放”的许可证授权方式。每次播放该内容，数据库就必须更新，减少授权使用的次数。用户可能会企图绕开这种保护机制，比方说在数据库更新从存储器载入硬盘驱动器之前就关闭设备。

R&CR 可测定数据库更新在存储器中“排队”的限度，超过了该上限，就必须更新到硬盘上的数据库版本中。这个限度通常定义为一定数量的歌曲或者一定的播放时间。如果系统支持闪存，那么即便发生断电更新队列也可以保存下来。不过，大多数硬盘驱动媒体播放器都不支持闪存等非易失存储器。（请注意，数据库更新不能缓冲存储到可移动介质，因为断电后用户可能会移动介质，这样就会删除更新队列。）



图 2b 显示了普通 DRM 的同一进程，不过 DRM 处理工作已经尽可能避开了关键任务路径，从而避免人们会感到出现操作延迟，且不影响性能。在预取缓冲区中存储许可证数据库可以在后台验证多个许可证，也有助于减少硬盘存取，进而延长电池使用寿命。


我们的目标是避免硬盘因实现 DRM 功能而增加转动频率。为了尽可能确保数据库的一致性，并尽可能减少所需的更新次数，系统需要监视其它硬盘驱动器转动请求，让数据库更新与这些请求同步进行。举例来说，播放器每预取一首歌，就能够且应当自动更新数据库。这样，许可证传输就能与数据传输同时进行，而这时用户是允许有延迟的。此外，如果有排队的更新，那么就应将数据库发生的变化写入硬盘驱动器，而不是写入整个数据库。

我们还能通过确定用户使用模式，预计用户要使用哪些内容，以此来减少硬盘转动频率。举例来说，如果用户倾向按照播放列表连续播放，那么播放器就能利用这种使用倾向。请注意，“随机”播放实际上并不一定要完全随机；播放器可以随机生成一个播放列表。用户可以预取几首歌，就像他们一般设定的播放列表一样，这样用户也能搜索此前播放的歌曲。确定用户的使用模式甚至能分辨出用户跳过某首歌的频率；这样随机播放期间选中用户不喜欢的歌曲的频率就会降低。


许可证传输

下载内容文件所需的时间是用户最不满意的地方。由于需要传输许可证，执行安全握手操作，并验证内容权限，因此 DRM 会影响传输时间。此外，降低 DRM 在许可证和内容传输方面的开销的办法就是在后台合理安排 DRM 工作任务，要么在其他工作之前执行，要么与其它操作同步进行。

处理许可证传输问题时还要记住，易用性尤其重要。用户希望只要选中歌曲就能播放。不过，DRM 的任务就是管理许可证权限，防止歌曲许可证过期后被播放，因此系统在执行该任务时必须做到高透明度，尊重用户。

管理许可证过期有着许多不同的机制，具体取决于使用何种 DRM 标准。在任何情况下，都要明确告诉用户什么过期了，怎么延期许可证。有时许可证会设定过期日期，即歌曲下载到便携式媒体播放器后能播放比方说一周的时间，然后继续播放就必须让播放器重新连接到可信的内容服务器（比如通过 PC 在因特网上连接到可信的服务器）。

为了尽可能避免用户混淆，播放器应能预测可能出现的问题。比如，用户出门旅行，最近一段时间都没有连接上网，这样定时许可证可能就会过期，让用户丢失使用权，懊恼不已。这些问题也会对 OEM 厂商实施有关技术提出挑战，因为 OEM 厂商可能并不能控制许可证更新的频率。减少上述问题的关键在于让用户适时了解限制性许可证信息（如在播放歌曲时显示过期日期或剩余播放次数等），以减少用户不必要的诧异。用户还应可以设定告警，如某个许可证有效期降到一定的阈值以下，系统就发出通知。无论如何，用户不能被恼人的告警信息所淹没 (比方说不用每首歌播放后都提醒)，否则他们就享受不到许可证播放带来的体验权利了。




从基本走向长远发展

DRM 的技术障碍不应影响性能、易用性或电池使用寿命，从而使DRM实施方案对任何希望支持DRM 功能的OEM 厂商都切实可行。尽管 DRM 机制会增加系统的复杂性，但在的情况下，这些主要问题都能得到充分解决且对基本系统架构影响极小。通过全面了解用户与媒体播放器的互动方式，开发人员可对 DRM 处理进行安排，确保其对播放器的启动、播放或许可证传输造成的影响尽可能小。

因此，开发人员面临的挑战不是说 DRM 到底能不能高效透明地实施，而在于如何在竞争对手中脱颖而出，让自己的设计方案超过成套的交钥匙子系统的基准功能，并为未来技术的发展做好准备。OEM 厂商应提供更透明的 DRM 功能，减少对启动、播放和传输时间的影响。为了通过实施最灵活的许可证管理方法支持各种的 DRM 协议，开发人员需要一种可编程的架构，配合全面加密功能 （如优化的加密库或加速硬件协处理器），以尽可能减少时延，降低功耗，为OEM 厂商提供尽可能多的选择机会。

举例来说，内容分配模型与 DRM 标准一样多种多样。有时用户可以自由彼此共享内容，然后再购买有效许可证，或只需同意通过网上账户为每次播放的内容支付许可费即可。超级分配模式下，用户可在手机等设备间方便地交换内容，还能保障有限的无线带宽。此外，新兴的移动虚拟网络运营商 (MVNO) 标准使任何公司都能从移动运营商处租赁空间，让用户随处访问更丰富的内容，今后还将支持所有设备的访问。

只有掌握最灵活的DRM实施方案的公司才能成为最具竞争力的公司。更重要的是，通过 MVNO 等技术创新，灵活实施DRM 技术的 OEM 厂商除推出播放器以外，还能为进入内容市场本身奠定基础，从而开创新的应用机遇和未来的增收机会。