软件超市授权下载机制对比与`其改进方案.docVIP

软件超市授权下载机制对比及其改进方案 　　摘　要：在现有的软件超市平台中，授权机制不能避免无限制地分散合法下载的软件，在此对此提出修正方案，对不同的下载软件设计出不同的流程，这意味攻击者不易开发出给一般人使用的通用工具，这样就可以增加软件的存活时间，而这也刚好解决了软件超市所出售软件生命周期短暂的问题 关键词：软件超市平台；　授权系统；　密钥分享问题；　软件生命周期 中图分类号：TN91934 文献标识码：A 文章编号：1004373X（2012 自从Apple　AppStroe的商业模式成功，使得许多大厂纷纷跟进，想要建立自己的软件超市平台，其中较著名的厂商包括Google和即将推出自主平台的Amazon等不同领域的主流厂商。这些厂商的软件超市都使用类似AppStore的架构，主要包括安装在客户端的近端商店软件以及服务器端的远端商店服务器：前者负责下载、更新、安装以及检查客户的软件状况；后者则负责软件上下架、展示以及远端管理客户的软件。与传统的电子商务不同之处在于近端商店软件，这个软件安装在消费者终端，平台运行商会比传统电子商务业者更了解消费者需求，增加消费者对平台运行商的忠诚度。而这样的趋势，使得客户端的软件保护更加重要，因为若上架软件很容易被非法复制，则就会减低开发者上架意愿，进而降低平台的下载量，造成恶性循环。从消费者观点来看，如果已经安装近端商店软件，但还是下载到了不安全软件，这同样会降低平台的下载量。因此，一个适当的软件授权机制关系到软件超市平台的运营情况［12］。但为了提高下载速度，平台的运营会使用内容传递网络（Content　Delivery　Network，CDN）技术［34］，从而限制软件授权机制的设计，因为内容传递网络技术就是将上架软件事先复制到全球各区域的服务器，通过分散下载点来加快反应速度，这意味着每一个消费者下载的软件都会一样，当平台的运营商无法下载时，针对不同消费者对下载软件做个别处理，而使得非法复制软件的情况更难防范。针对这点，本文将进行讨论并提出其改进方案 1　相关工作 首先介绍传统的软件授权方式，不外乎如微软的使用者授权（EndUser　License　Agreement，EULA），原始设备商授权（OEM）以及大量授权。前两者的授权方式都是将授权信息随软件套件或终端给使用者，再加上安装完毕的启动动作来加强安全性，因为会对每一个软件套件做差异化，并不适合应用在内容传递网络技术，而后者则是在企业或组织的内部网络架设授权服务器，软件启动会连到这台授权服务器，除此之外还会定期检查软件授权状态检查，要是太久没有做授权更新，就会被停止使用，这样的使用情境类似现有的软件超市应用，其差异是没有考虑跨网域的安全性 在不考虑软件上/下架管理情况下，软件超市平台其实就是一个跨网域的授权系统，由于要授权多种软件给消费者，所以需要于客户端终端安装近端商店软件来管理不同软件的授权。而不同的软件超市平台的差异在于包装授权方式不同，如Amazon　AppStore及Android　Market会以非对称方式密码算法，而Apple　Appstore则使用对称方式密码算法，但无论是哪种方式，都因为使用　CDN技术，而易遭受取代攻击，造成合法下载的软件被非法复制传播。关于这两个软件超市平台运作流程，将在下一段说明。Android　Market的授权系统核心License　Verification　Library（LVL），软件开发者将LVL相关程序加入自己的软件后，当消费者执行此程序，就会与Android　Market的授权系统通信检查授权状况。软件开发者使用LVL的步骤包含： 上网申请公开密钥，相对应的私密密钥会存放于Android　Market　的授权系统。申请好的公开密钥，将软件开发者直接复制在源代码中，并通过函数传递LVL模组，主要用来验证由远端传来的授权文件。所申请的公开密钥会以Base64方式编码，如图1所示，开发者只要复制/粘贴就可以放进源代码 开发者复制/粘贴此公开密钥并嵌入LVL相关的程序后，所发展的软件就可经由近端商店软件（Market　App）向远端的授权服务器做查询，保护自己的软件 图1　LVL　License　Key远端的授权流程如图2所示。流程概述如下，当消费者想要执行程序（myAPP），步骤2内嵌的LVL程序会与近端商店软件沟通，传递软件信息（App　Data），收到信息的近端商店软件便会加上消费者信息（User　Data），与远端的授权服务器沟通，远端的授权服务器用传来的信息查询数据库，然后传回经过签章的授权状态（License　Status），这个经过签章的授权状态最后会传到myAPP，先使用公开密钥验签章，再依授权状态内容决定是否