IT博客-心无尘土-随笔分类-DRM, 网络安全，security

DRM(SuperDistribution)探究之三：如何通过可移动存储设备来进行MIDlet suites的超分

Yama的家 — Thu, 19 Oct 2006 02:02:00 GMT

1.机制
Between two devices a MIDlet suite(as a MIDlet message or a DCF file) is saved to and then read from the RMSD.

2.流程
①The user of the sending device selects the suite to be placed on the RMSD
②The device makes a decision on the format to be used for superdistribution
③The suite is placed to the RMSD(as a MIDlet Message or as a DCF file)
④The user of the sending device passes the RMSD to the user of the receiving device
⑤The user of the receiving device inserts the RMSD into the device and uses the device UI access the suite(as a MIDlet Message or as a DCF file)
⑥The suite is installed on the receiving device

Yama的家 2006-10-19 10:02 发表评论

DRM(SuperDistribution)探究之二：超分的发送与接受

Yama的家 — Tue, 17 Oct 2006 09:01:00 GMT

1.超分的对象
OMA Superdistribution is allowed only for the content that was deliverd using OMA separate delivery method unless the DCF containing the jar file was received in a DRM message without rights.也就是说只有一般的separate才可以支持超分，而特殊的Forword-lock的separate不支持。

2.发送过程
    ①Presence of the JAD file is checked.
    ②If the JAD file is present and contains the jar file's digital signature and the device contains the rights object to access the JAR in the DCF, the integrity of the JAR file is checked before sending the suite. if the integrity check fails, the suite is not sent.An error message is shown to the user.问题在于没有rights的话就没有必要管，但是现在有rights的就是安装完成的，必然是正确的，所以是多此一举。还有就是如果错误的话，什么样的错误信息给用户.既然错误了,为什么不删除既有的文件
    ③If the JAD file is missing, only t.he DCF file with the JAR file inside is sent from the device and wrap to midlet message is ignored.只有DCF没有Jad的话，就不用专门作MIDletMessage，而直接传dcf，如果单独的dcf不被支持的话，可以不用考虑单独传送dcf的情况。但是一般的jadjar也是可以用superdistribution的，所以jad和jar需要作成特殊的midletmessage,用jar代替dcf.还有一般的单独jar,是不是就是传送单独的jar文件了。
    ④JAD and DCF are placed to the container JAR file.Plain structure is used, the JAD and DCF are placed to in the root of the container JAR file(no folders). Three manifest attribute are placed to the manifest of the container Jar file.
    ⑤The name of container JAR file is the value of MIDlet-Name attribute in the JAD file. The extension is jar
    ⑥A superdistributed MIDlet suite may not work on the other device due to multiple reasons.Therefore, the user of the sending device has to be notified about this risk.This is done by displaying an appropriate prompt before sending of a suite. 简单的说，就是超分的时候需要开始时候给用户提示信息。加个确认对话框的说
    ⑦通过蓝牙或者红外等技术超分的时候，如果对方不支持接受MIDletsuites的话有必要在发送端给用户错误信息的提示。

3.接受过程
    ①支持的类型MIDlet Message和DCF file with the only JAR file inside.
    ②安装：The user has a possibility to install a MIDlet suite contained in the received DCF file or MIDlet message.
    ③In here, suite installation is understood as a process resulting in ability of the user to run MIDlets from the suite.This process includes MIDP verifications, possible acquisition of rights,etc, MIDP installation status reporting and deletion notification are not done for Surperdistribution suites.这部分
感觉也很怪，毕竟作为安装来说不发送安装报告是违反midp2.0文档的，同时现在从菜单来取得权力的安装和这种非常类似，如果该安装不用发送状态报告的话，getrights是不是也不用发送呢？？疑惑！！！！

Yama的家 2006-10-17 17:01 发表评论

DRM(SuperDistribution)探究之一：MIDlet Message

Yama的家 — Mon, 16 Oct 2006 08:00:00 GMT

    MIDlet Message是超分（SuperDistribution）中间出现的最重要的概念之一。它定义了MIDlet suites在超分时候的传输格式。
    1.在OMA的Implementation Best Practices for OMA DRM v1.0 protected MIDlets的文档5.3章里面明确的指出
[It is a JAR file that contains a JAD file and a JAR file in the DCF].
    2.The container JAR file is created as per the ZIP archive format specification and also the JAR file specification.Compression is not used for container JAR file.也就是说做成无压缩的jar文件，但是zip的格式必须遵循。
    3.The container JAR file is always contains exactly one JAD file and exactly one JAR file in the DCF file.
    4.The MIME type of the container JAR file is application/java-archive.好像这条对于实装没有什么用。
    5.The manifest of the JAR file(named "manifest.mf") is placed to the META-INF directory.值得注意的是用Sun的jar工具作出来的jar都是自动把manifest.mf变成了大写MANIFEST.MF。而OMA的文档里面特别将说明和例子里面的manifest.mf都用的是小写。不知道有何用意。总之，准备用[该部分的作成时候用小写写入，读入文件的时候无论大小写都可以接受]的方案来实现。
    6.The manifest file contains the following attributes.
       Distribution-Package: x.y(Midlet Message的版本号，对于本文档而言是1.0)
      Distribution-Descriptor-Filename: xxx.jad(The name of the jad file with the full path inside the container jar file感觉全路径是废话，因为在message文件里面jad没有上部文件夹)
      Distribution-Content-Filename: xxx.dcf(The name of the jar file in the DCF)
    7.When creating MIDlet message, JAD and DCF files are placed to the root of the container JAR file, not in any folders.
    8.Names of JAD and DCF files inside the MIDletMessage can be obtained from上面的两属性
    9.The software that deals with unpacking of MIDlet Message should support any order of files.也就是说读取文件的时候不能按顺序解析。需要找寻索引得到文件名，然后对应解析.
    10.Note, that the MIDlet Message format can also be used for forwarding of MIDlet suites that are not OMA DRM protected.(if the device allows so).文件变成manifest,jad,jar的格式？？？
    11.Note also, the MIDlet Message format is not intended for delivery of MIDlet suites OTA.也就是说在现行的midp对应的jar直接安装里面要能够分析出来这种情况的文件，而不能导致异常的出现。

Yama的家 2006-10-16 16:00 发表评论

DRM环境搭建

Yama的家 — Mon, 03 Apr 2006 07:19:00 GMT

摘要: 阅读全文

Yama的家 2006-04-03 15:19 发表评论

DRM实装前式样问题点二之Combined delivery篇

Yama的家 — Fri, 24 Mar 2006 11:26:00 GMT

摘要: 阅读全文

Yama的家 2006-03-24 19:26 发表评论

DRM实装前式样问题点一之Forward-lock篇

Yama的家 — Fri, 24 Mar 2006 11:09:00 GMT

1． Forward-lock method

· Jar file wrapped into the DRM message.(a message containing a media object and optional rights object)

->MIDlet-Jar-Url 里面指向的是 DRM message(Jar)

-> 对于用户来说下载户过程和没有保护的下载一样

· In case when the JAD file is present / If there is no JAD file available

->JAD 文件存在的 case

1．通过应用程序下载 JAD

2．如果用户愿意下载 MIDlet Suite, 通过 MIDlet-Jar-URL 找到 DRM Message 。

-> 没有 JAD 文件的 case

1．立刻开始下载 DRM Message

->DRM message ： application/vnd.oma.drm.message MIME type

· After download message, the process continues as in MIDP OTA download

->JAD file 的 MIDlet-Jar-Size 一直是和 JAR file 的大小比较，而不是和 DRM message 的大小比较。 （取大小的时候不是取下载包大小，而是从 message 中间提出 Jar 后看大小）

· MIDP installation status reporting is also done as normal but need a new code

->Non-Acceptable Content 503

1．检查取得的 DRM message 的有效性（设备解析不了的时候无效）

2．解析原则参考 DRM Content Format （解析函数什么地方？？？）

Yama的家 2006-03-24 19:09 发表评论

PKI 5 CA模式产生背景和基本原理

Yama的家 — Tue, 21 Mar 2006 12:08:00 GMT

摘要: 证书就是证明密钥拥有者身份的凭证。
而CA就是公开的，可以发行证书的机关。用户也可以从他那里获取你可以信任的证书，还可以知道要作废的证书阅读全文

Yama的家 2006-03-21 20:08 发表评论

PKI temp X509

Yama的家 — Mon, 20 Mar 2006 10:31:00 GMT

摘要: 要点
证书就是为了证明公开钥发行者是真的阅读全文

Yama的家 2006-03-20 18:31 发表评论

DRM(Digital Rights Management)

Yama的家 — Mon, 20 Mar 2006 02:36:00 GMT

摘要: DRM的基本概念以及关于DRM在便携式设备（主要指手机）上关于J2ME的MIDP下载部分的DRM实现注意点阅读全文

Yama的家 2006-03-20 10:36 发表评论

PKI 4 数字签名

Yama的家 — Fri, 17 Mar 2006 07:52:00 GMT

摘要: 数字签名和认证方面概述

BTW:
有在做关于DRM方面的人么，有兴趣可以探讨一下互相的领域，
我最近要做关于手机方面的drm处理，具体来说是关于Implementation Best practices for OMA DRM protected MIDLets. 阅读全文

Yama的家 2006-03-17 15:52 发表评论

PKI 3 安全哈希函数

Yama的家 — Fri, 17 Mar 2006 05:41:00 GMT

摘要: 欲哭无泪阿，这篇文章我总共写了3次，每次都不小心忘了保存。
看来hash函数的确是带着诅咒来到世界，要不然从md4到md5都被人破的光光，号称标准的sha-1也危及四伏
我们的世界究竟什么才是安全。电子签名起码看上去不是那么可怕，所以的技术防的是君子而不是小人。
也许不久的明天，网络上看到的每一个需要你信息的地方都有人在潜伏着，我们透明的活着阅读全文

Yama的家 2006-03-17 13:41 发表评论

PKI 2 加密算法

Yama的家 — Thu, 16 Mar 2006 03:26:00 GMT

摘要: Symmetric cryptography和Public Key Cryptography的概述
技术方面的总揽
然后以此为基础,探讨数字签名等阅读全文

Yama的家 2006-03-16 11:26 发表评论

PKI 1 概要

Yama的家 — Wed, 15 Mar 2006 07:47:00 GMT

PKI                                                                                                             Yama于20060315
    Public Key Infrastructure
    公开密钥基础设施
    公開鍵基盤

基础
它是公开密钥理论和技术上发展的综合安全平台.
1。CA (Certificate Authority) 认证中心
    负责产生，分配并且管理数字证书的可信赖的第三方权威机构。
    采用分级机构，上级认证中心负责签发和管理下级认证中心的证书，最下一级直接面向最终用户

2。数字证书
    由认证中心发放并且认证中心数字签名的，包含公开密钥拥有者及其相关消息的文件，可以用来证明数字证书持有者的真实身份。
    采用公开密钥体制。每个用户自己设定私钥，用它解密和验证数字签名。同时设定公钥并有本人公开，用于加密和验证签名。发送机密文件时，发送方使用接受方的公钥加密，接受方用自己的私钥解密。


网络的广泛性和开放性,也就决定了它的安全隐患性.
常见安全性问题及其解决手段
1.盗听　盗聴
解决方法->网络上流通数据加密

2.违法访问　不正アクセス
   手段
       a.用词典工具对正常用户进行暴力破解
       b.利用服务器中的安全漏洞
   解决方法->防火墙，及对服务器中重要数据加密保存

3.伪装なりすまし
方式
    a.正规用户情报盗听后，利用得到的认证情报
    b.假冒电子邮件的发件人名字
解决方法->加强认证方法，增加数字签名

4.篡改改竄
解决方法->增加数字签名

5.否认否認
解决方法->确认发生在有当事人认证和数字签名的环境

功能
1。暗号化 Encryption 加密
2。デジタル署名 Digital Signature 数字签名

目的
1。Confidentiality 守秘性
2。Authentication 认证
3。Integrity 完整性
4。Non-Repudiation 否認防止

                                                                                                                Yama于20060315

Yama的家 2006-03-15 15:47 发表评论

SSL入门

Yama的家 — Thu, 09 Mar 2006 07:55:00 GMT

1
SSL(Server Socket Layer)
->RFC2246标准化：TLS (Transport Layer Security)

2
简单说SSL就是用不对称加密技术实现会话双方之间信息的安全传递。
建立SSL安全连接使用https://ip:port/的方式，不同于http协议

3
https安全连接的建立：本地浏览器与Web Server间身份认证及密钥交换的握手过程
   1。本地浏览器-〉服务器
       （SSL版本号，加密设置参数，session有关数据及其他一些必要消息）
   2。服务器-〉本地浏览器
      （SSL版本号，加密设置参数，session有关数据及其他一些必要消息
         服务器的证书
         如果需要用户身份认证，发出要求让本地浏览器提供用户证书）
   3。本地
         检查服务器证明书
         失败：不能建立SSL连接
         成功：继续
   4。本地为会话生成pre-master secret
         本地-〉服务器
         （用服务器公钥加密的pre-master secret）
   5。本地-〉服务器
         见2最后，如果需要，客户端还要对另外一些数据签名后和客户端证书一起发送给服务器
   6。同上，见2最后，如果需要鉴别客户身份。
         检查签署客户身份的CA是否可信
         不在信任列表-〉结束本次会话
         检查通过-〉服务器用私钥解密收到的pre-master secret，并通过算法生成本次会话的master secret
   7。双方都用该master secret生成本次会话的会话密钥（对称密钥），握手结束后一直用该密钥传递消息
   8。客户端-〉服务器
         通知服务器，客户端已完成本次SSL握手
   9。服务器-〉客户端
         通知客户端，服务器已完成本次SSL握手
   10。会话建立，通话用对称密钥加解密

Yama的家 2006-03-09 15:55 发表评论