BlogJava-A Cooly Weblog

Web Service理论－SOAP

acooly — Fri, 04 Jul 2008 09:23:00 GMT

什么是WebServcie

网上有很多解释版本。我是技术研发，所以个人理解从技术角度说：Web Service是一种轻量级别的基于XML的跨平台远程服务通讯框架技术，可以很好解决各平台和语言间的数据通讯。

语意协议：使用基于XML的SOAP协议，定义业务数据格式。
传输协议：使用HTTP,TPC/IP,FTP,SMTP和JMS等，一般采用和支持较多的是HTTP。
接口描述语言：使用基于XML的WDSL作为统一服务描述。

简单的说，WEBSERVICE就是规定一系列的规范和框架，提供一个基于SOA（面向服务的架构）概念的使用WSDL来描述服务接口定义的方案，可以使用传统的传输协议（一般使用HTTP）传输基于XML的SOAP格式报文数据来实现跨平台间系统的通讯。下面分别介绍WEBSERVICE中必须了解的几个部分：SOAP,WSDL和传输协议

SOAP

简单对象访问协议（SOAP：Simple Object Access Protocol）是一种轻量的、简单的、基于 XML 的协议，它被设计成在 WEB 上交换结构化的和固化的信息。主要负责在WEBSERVICE服务中通讯报文数据格式的定义。 SOAP 可以和现存的许多因特网协议和格式结合使用，包括超文本传输协议（ HTTP），简单邮件传输协议（SMTP），多用途网际邮件扩充协议（MIME），传统SOCKET通讯(TCP/IP),JAVA消息系统(JMS)等传输协议。它还支持从消息系统到远程过程调用（RPC）等大量的应用程序。

　SOAP 包括三个部分：

SOAP 封装：它定义了一个框架，该框架描述了消息中的内容是什么，谁应当处理它以及它是可选的还是必须的。
SOAP 编码规则：它定义了一种序列化的机制，用于交换应用程序所定义的数据类型的实例。
SOAP RPC 表示：它定义了用于表示远程过程调用和应答的协定。

　　SOAP 消息基本上是从发送端到接收端的单向传输，但它们常常结合起来执行类似于请求 / 应答的模式。所有的 SOAP 消息都使用 XML 编码。一条 SOAP 消息就是一个包含有一个必需的 SOAP 的封装包，一个可选的 SOAP 标头和一个必需的 SOAP 体块的 XML 文档。

　　把 SOAP 绑定到 HTTP 提供了同时利用 SOAP 的样式和分散的灵活性的特点以及 HTTP 的丰富的特征库的优点。在 HTTP 上传送 SOAP 并不是说 SOAP 会覆盖现有的 HTTP 语义，而是 HTTP 上的 SOAP 语义会自然的映射到 HTTP 语义。在使用 HTTP 作为协议绑定的场合中， RPC 请求映射到 HTTP 请求上，而 RPC 应答映射到 HTTP 应答。简单的说就是，通过HTTP POST（当然也可以GET或其它，一般是POST）方式传输一个SOAP协议定义的报文数据体，用于双向通讯。然而，在 RPC 上使用 SOAP 并不仅限于 HTTP 协议绑定，也可以和其他的现行传输协议绑定。

语法规则

SOAP 消息必须用 XML 来编码
SOAP 消息必须使用 SOAP Envelope 命名空间
SOAP 消息必须使用 SOAP Encoding 命名空间
SOAP 消息不能包含 DTD 引用
SOAP 消息不能包含 XML 处理指令

SOAP报文结构

一条 SOAP 消息就是一个普通的 XML 文档，包含下列元素：

必需的 Envelope标签，文档的ROOT，可把此 XML 文档标识为一条 SOAP 消息
必需的 SOAP 的 Envelope 元素是 SOAP 消息的根元素。它可把 XML 文档定义为 SOAP 消息
可选的 Header标签，包含头部信息
可选的 SOAP Header 元素可包含有关 SOAP 消息的应用程序专用信息（比如认证、支付等）。如果 Header 元素被提供，则它必须是 Envelope 元素的第一个子元素。
必需的 Body标签，包含所有的调用和响应信息
必需的 SOAP Body 元素可包含打算传送到消息最终端点的实际 SOAP 消息。
SOAP Body 元素的直接子元素可以是合格的命名空间。SOAP 在默认的命名空间中("http://www.w3.org/2001/12/soap-envelope")定义了 Body 元素内部的一个元素。即 SOAP 的 Fault 元素，用于指示错误消息。
可选的 Fault 元素，提供有关在处理此消息所发生错误的信息
来自 SOAP 消息的错误消息被携带于 Fault 元素内部。
如果已提供了 Fault 元素，则它必须是 Body 元素的子元素。在一条 SOAP 消息中，Fault 元素只能出现一次。
SOAP 的 Fault 元素用于下列子元素：
子元素描述
供识别故障的代码
可供人阅读的有关故障的说明
有关是谁引发故障的信息
存留涉及 Body 元素的应用程序专用错误信息

子元素	描述
	供识别故障的代码
	可供人阅读的有关故障的说明
	有关是谁引发故障的信息
	存留涉及 Body 元素的应用程序专用错误信息

SOAP请求报文

<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" //SOAP报文默认命名空间
                   xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/" //编码数据类型命名空间
                   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"//文档XSD实例方案，规定格式
                   xmlns:xsd="http://www.w3.org/2001/XMLSchema">         //文档XSD方案，规定格式

    <SOAP-ENV:Body>
        <m:activateEpurse xmlns:m="http://service.payment.ipayment.justinmobile.com">
            <m:appNo>Stringm:appNo>
            <m:mobileNo>Stringm:mobileNo>
        m:activateEpurse>
    SOAP-ENV:Body>
SOAP-ENV:Envelope>

SOAP应答报文（返回一个entry数组，也就是MAP）

<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
    <soap:Body>
        <ns1:activateEpurseResponse xmlns:ns1="http://service.payment.ipayment.justinmobile.com">
            <ns1:out>
                <entry xmlns="http://service.payment.ipayment.justinmobile.com">
                    <key>transStatuskey>
                    <value>0001value>
                entry>
            ns1:out>
        ns1:activateEpurseResponse>
    soap:Body>
soap:Envelope>

所有以上的元素均被声明于针对 SOAP 封装的默认命名空间中：

http://www.w3.org/2001/12/soap-envelope

SOAP 在默认的命名空间中 ("http://www.w3.org/2001/12/soap-envelope") 定义了三个属性。这三个属性是：actor、 mustUnderstand 以及 encodingStyle。这些被定义在 SOAP 头部的属性可定义容器如何对 SOAP 消息进行处理。

actor

通过沿着消息路径经过不同的端点，SOAP 消息可从某个发送者传播到某个接收者。并非 SOAP 消息的所有部分均打算传送到 SOAP 消息的最终端点，不过，另一个方面，也许打算传送给消息路径上的一个或多个端点。

SOAP 的 actor 属性可被用于将 Header 元素寻址到一个特定的端点。

soap:actor="URI"

mustUnderstand

SOAP 的 mustUnderstand 属性可用于标识标题项对于要对其进行处理的接收者来说是强制的还是可选的。

假如您向 Header 元素的某个子元素添加了 "mustUnderstand="1"，则它可指示处理此头部的接收者必须认可此元素。假如此接收者无法认可此元素，则在处理此头部时必须失效。

soap:mustUnderstand="0|1"

encodingStyle

SOAP 的 encodingStyle 属性用于定义在文档中使用的数据类型。此属性可出现在任何 SOAP 元素中，并会被应用到元素的内容及元素的所有子元素上。SOAP 消息没有默认的编码方式。

soap:encodingStyle="http://www.w3.org/2001/12/soap-encoding"

以及针对 SOAP 编码和数据类型的默认命名空间：

http://www.w3.org/2001/12/soap-encoding

acooly 2008-07-04 17:23 发表评论

SVN-WINDOWS服务器架设和管理

acooly — Sun, 08 Jun 2008 04:40:00 GMT

摘要: SVN-WINDOWS 服务器架设和管理 1. 环境和软件准备 ... 阅读全文

acooly 2008-06-08 12:40 发表评论

RSA非对称加密JAVAAPI实现

acooly — Tue, 27 May 2008 05:41:00 GMT

package org.acooly.studio.encrypt;

import java.security.KeyPair;
import java.security.KeyPairGenerator;
import java.security.PrivateKey;
import java.security.PublicKey;

import javax.crypto.Cipher;

import org.apache.commons.logging.Log;
import org.apache.commons.logging.LogFactory;

/** *****************************************************************************
* 非对称加密JAVA算法演示(JAVA-SUN API实现)

* 算法:RSA

* RSA算法是第一个能同时用于加密和数字签名的算法，也易于理解和操作。
* RSA是被研究得最广泛的公钥算法，从提出到现在已近二十年，经历了各种攻击的考验，逐渐为人们接受，普遍认为是目前最优秀的公钥方案之一。RSA的安全性依赖于大数的因子分解，但并没有从理论上证明破译RSA的难度与大数分解难度等价。即RSA的重大缺陷是无法从理论上把握它的保密性能如何，而且密码学界多数人士倾向于因子分解不是NPC问题。RSA的缺点主要有：A)产生密钥很麻烦，受到素数产生技术的限制，因而难以做到一次一密。B)分组长度太大，为保证安全性，n
* 至少也要 600
* bits以上，使运算代价很高，尤其是速度较慢，较对称密码算法慢几个数量级；且随着大数分解技术的发展，这个长度还在增加，不利于数据格式的标准化。目前，SET(Secure
* Electronic Transaction)协议中要求CA采用2048比特长的密钥，其他实体使用1024比特的密钥。

* 这种算法1978年就出现了，它是第一个既能用于数据加密也能用于数字签名的算法。它易于理解和操作，也很流行。算法的名字以发明者的名字命名：Ron
* Rivest, AdiShamir 和Leonard Adleman。但RSA的安全性一直未能得到理论上的证明。

* RSA的安全性依赖于大数分解。公钥和私钥都是两个大素数（大于
* 100个十进制位）的函数。据猜测，从一个密钥和密文推断出明文的难度等同于分解两个大素数的积。

* 密钥对的产生。选择两个大素数，p 和q 。计算：

* n = p * q

* 然后随机选择加密密钥e，要求 e 和 ( p - 1 ) * ( q - 1 ) 互质。最后，利用Euclid 算法计算解密密钥d, 满足

* e * d = 1 ( mod ( p - 1 ) * ( q - 1 ) )

* 其中n和d也要互质。数e和n是公钥，d是私钥。两个素数p和q不再需要，应该丢弃，不要让任何人知道。

* 加密信息 m（二进制表示）时，首先把m分成等长数据块 m1 ,m2,, mi ，块长s，其中 2^s <= n, s 尽可能的大。对应的密文是：
*

* ci = mi^e ( mod n ) ( a )

* 解密时作如下计算：

* mi = ci^d ( mod n ) ( b )

* RSA 可用于数字签名，方案是用 ( a ) 式签名， ( b )式验证。具体操作时考虑到安全性和 m信息量较大等因素，一般是先作 HASH 运算。
*

* RSA 的安全性。

* RSA的安全性依赖于大数分解，但是否等同于大数分解一直未能得到理论上的证明，因为没有证明破解RSA就一定需要作大数分解。假设存在一种无须分解大数的算法，那它肯定可以修改成为大数分解算法。目前，
* RSA的一些变种算法已被证明等价于大数分解。不管怎样，分解n是最显然的攻击方法。现在，人们已能分解140多个十进制位的大素数。因此，模数n必须选大一些，因具体适用情况而定。
*

* RSA的速度。

* 由于进行的都是大数计算，使得RSA最快的情况也比DES慢上100倍，无论是软件还是硬件实现。速度一直是RSA的缺陷。一般来说只用于少量数据加密。

* RSA的选择密文攻击。

* RSA在选择密文攻击面前很脆弱。一般攻击者是将某一信息作一下伪装(Blind)，让拥有私钥的实体签署。然后，经过计算就可得到它所想要的信息。实际上，攻击利用的都是同一个弱点，即存在这样一个事实：乘幂保留了输入的乘法结构：
*
( XM )^d = X^d *M^d mod n

* 前面已经提到，这个固有的问题来自于公钥密码系统的最有用的特征--每个人都能使用公钥。但从算法上无法解决这一问题，主要措施有两条：一条是采用好的公钥协议，保证工作过程中实体不对其他实体任意产生的信息解密，不对自己一无所知的信息签名；另一条是决不对陌生人送来的随机文档签名，签名时首先使用One-Way
* Hash Function对文档作HASH处理，或同时使用不同的签名算法。在中提到了几种不同类型的攻击方法。

* RSA的公共模数攻击。

* 若系统中共有一个模数，只是不同的人拥有不同的e和d，系统将是危险的。最普遍的情况是同一信息用不同的公钥加密，这些公钥共模而且互质，那末该信息无需私钥就可得到恢复。设P为信息明文，两个加密密钥为e1和e2，公共模数是n，则：
* C1 = P^e1 mod n

* C2 = P^e2 mod n

* 密码分析者知道n、e1、e2、C1和C2，就能得到P。

* 因为e1和e2互质，故用Euclidean算法能找到r和s，满足：

* r * e1 + s * e2 = 1

* 假设r为负数，需再用Euclidean算法计算C1^(-1)，则
( C1^(-1) )^(-r) * C2^s = P mod n

* 另外，还有其它几种利用公共模数攻击的方法。总之，如果知道给定模数的一对e和d，一是有利于攻击者分解模数，一是有利于攻击者计算出其它成对的e’和d’，而无需分解模数。解决办法只有一个，那就是不要共享模数n。

* RSA的小指数攻击。
* 有一种提高RSA速度的建议是使公钥e取较小的值，这样会使加密变得易于实现，速度有所提高。但这样作是不安全的，对付办法就是e和d都取较大的值。

*
* @author pu.zhang
*
*/
public class DisSymmetricEncryption {

     private Log logger = LogFactory.getLog(DisSymmetricEncryption. class );

     public static void main(String[] args) throws Exception {
        DisSymmetricEncryption disSymmetricEncryption = new DisSymmetricEncryption();
        disSymmetricEncryption.RSAEncryption();
    }

     /**
     * RSA加/解密JAVA-API演示

     * 加密可以用公钥，解密用私钥；或者加密用私钥，解密用公钥。通常非对称加密是非常消耗资源的，因此可以对大数据用对称加密如：
     * DES或3DES，而对其对称密钥进行非对称加密，这样既保证了数据的安全，还能保证效率。
      */
     void RSAEncryption() throws Exception {
        String algorithm = " RSA " ;
        logger.info( " algorithm: " + algorithm);
         // 明文
         byte [] plainText = { 0 , 1 , 2 , 3 , 4 , 5 , 6 , 7 , 8 , 9 } ;
        logger.info( " plainText: " + formatedHexString(plainText));

         // 生成KeyPaire
        KeyPairGenerator keyPairGenerator = KeyPairGenerator.getInstance( " RSA " );
        keyPairGenerator.initialize( 1024 );
        KeyPair keyPair = keyPairGenerator.genKeyPair();

         // 公钥
        PublicKey publickKey = keyPair.getPublic();
        logger.info( " PublicKey: " + formatedHexString(publickKey.getEncoded()));
         // 私钥
        PrivateKey privateKey = keyPair.getPrivate();
        logger.info( " PrivateKey: " + formatedHexString(privateKey.getEncoded()));

        Cipher cipher = Cipher.getInstance( " RSA " );
         // 公钥加密
        cipher.init(Cipher.ENCRYPT_MODE, publickKey);
         byte [] publicKeyEncryptText = cipher.doFinal(plainText);
        logger.info( " publicKeyEncryptText: " + formatedHexString(publicKeyEncryptText));
         // 私钥解密
        cipher.init(Cipher.DECRYPT_MODE, privateKey);
         byte [] privateKeyDecryptText = cipher.doFinal(publicKeyEncryptText);
        logger.info( " privateKeyDecryptText: " + formatedHexString(privateKeyDecryptText));

         // 私钥加密
        cipher.init(Cipher.ENCRYPT_MODE, privateKey);
         byte [] privateKeyEncryptText = cipher.doFinal(plainText);
        logger.info( " privateKeyEncryptText: " + formatedHexString(privateKeyEncryptText));
         // 公钥解密
        cipher.init(Cipher.DECRYPT_MODE, publickKey);
         byte [] publicKeyDecryptText = cipher.doFinal(privateKeyEncryptText);
        logger.info( " publicKeyDecryptText: " + formatedHexString(publicKeyDecryptText));


    }

     /**
     * 转换byte数组为16进制的字符串显示方式
     * @param b
     * @return
      */
    String formatedHexString( byte [] b) {
        String hs = "" ;
        String stmp = "" ;

         for ( int n = 0 ; n < b.length; n ++ ) {
            stmp = (java.lang.Integer.toHexString(b[n] & 0XFF ));
             if (stmp.length() == 1 )
                hs = hs + " 0 " + stmp;
             else
                hs = hs + stmp;
             if (n < b.length - 1 )
                hs = hs + " " ;
        }
         return hs.toUpperCase();
    }

}

acooly 2008-05-27 13:41 发表评论

windows下自动启动svn的svnserved脚本

acooly — Sat, 24 May 2008 17:34:00 GMT

set WshShell = WScript.CreateObject( " WScript.Shell " )
WshShell.run " svnserve -d -r h:/repository " , 0 , true

把上面脚本保存为:auto_run_svnserve.vbs，然后加入到启动里面或是注册表run里面，系统启动的时候就自动启动了svnserve服务。注意：红色部分为你的仓库的物理地址。

acooly 2008-05-25 01:34 发表评论

对成加密JAVA-API实现

acooly — Fri, 23 May 2008 15:21:00 GMT

  1 package org.acooly.studio.encrypt;
  2
  3 import java.security.Key;
  4
  5 import javax.crypto.Cipher;
  6 import javax.crypto.KeyGenerator;
  7 import javax.crypto.SecretKey;
  8 import javax.crypto.spec.IvParameterSpec;
  9 import javax.crypto.spec.SecretKeySpec;
10
11 import org.apache.commons.logging.Log;
12 import org.apache.commons.logging.LogFactory;
13
14 /**
15  * 对称加密JAVA算法演示(JAVA-SUN API实现)
16  *
17  *
18  * @author pu.zhang
19  *
20  */
21 public class SymmetricEncryption {
22
23     private Log logger = LogFactory.getLog(SymmetricEncryption.class);
24
25     public static void main(String[] args) throws Exception {
26
27         SymmetricEncryption symmetricEncryption = new SymmetricEncryption();
28
29         // DES
30         symmetricEncryption.DESEncryption();
31         // 3DES
32         symmetricEncryption.tripleDESEncryption();
33
34     }
35
36     /**
37      * DES加/解密演示
38      *
39      * @throws Exception
40      */
41     void DESEncryption() throws Exception {
42
43         // 明文
44         byte[] plainText = "I am plain text!".getBytes();
45
46         logger.info("明文:" + formatedHexString(plainText));
47         // 通过KeyGenerator形成一个key
48         KeyGenerator keyGenerator = KeyGenerator.getInstance("DES");
49         Key key = keyGenerator.generateKey();
50         logger.info("KEY:" + formatedHexString(key.getEncoded()));
51
52         // 获得一个私钥加密类Cipher，CBC是加密方式，PKCS5Padding是填充方法
53         // CBC加密方式：把明文分为左右两部分LP和RP
54         String transformation = "DES/CBC/PKCS5Padding"; // algorithm/mode/padding
55         Cipher cipher = Cipher.getInstance(transformation);
56
57         // CBC方式的初始化向量
58         byte[] iv = "iamaniv.".getBytes();
59         IvParameterSpec ivparam = new IvParameterSpec(iv);
60         // 加密
61         cipher.init(Cipher.ENCRYPT_MODE, key, ivparam);
62         byte[] cipherText = cipher.doFinal(plainText);
63         logger.info("加密后密文:" + formatedHexString(cipherText));
64
65         // 解密
66
67         cipher.init(Cipher.DECRYPT_MODE, key, ivparam);
68         byte[] newPlainText = cipher.doFinal(cipherText);
69         logger.info("解密后明文:" + formatedHexString(newPlainText));
70     }
71
72     /**
73      * DES加/解密演示
74      *
75      * @throws Exception
76      */
77     void tripleDESEncryption() throws Exception {
78         // 24字节密钥key,3倍DES密钥长度
79         byte[] tripleKey = "123456789012345678901234".getBytes();
80         logger.info("tripleKey:" + formatedHexString(tripleKey));
81         // 明文
82         byte[] plainText = "I am plain text!".getBytes();
83         logger.info("初始的明文:" + formatedHexString(plainText));
84
85         // 算法
86         String algorithm = "DESede";
87
88         // 生成密钥
89         SecretKey secretKey = new SecretKeySpec(tripleKey, algorithm);
90
91         String transformation = "DESede/CBC/PKCS5Padding";
92         Cipher cipher = Cipher.getInstance(transformation);
93         // CBC方式的初始化向量
94         byte[] iv = "iamaniv.".getBytes();
95         IvParameterSpec ivparam = new IvParameterSpec(iv);
96
97         // 加密
98         cipher.init(Cipher.ENCRYPT_MODE, secretKey, ivparam);
99         byte[] encriptText = cipher.doFinal(plainText);
100         logger.info("加密的密文:" + formatedHexString(encriptText));
101
102         // 解密码
103         cipher.init(Cipher.DECRYPT_MODE, secretKey, ivparam);
104         byte[] newPlainText = cipher.doFinal(encriptText);
105         logger.info("解密的明文:" + formatedHexString(newPlainText));
106     }
107
108
109     /**
110      * 转换byte数组为16进制的字符串显示方式
111      * @param b
112      * @return
113      */
114     String formatedHexString(byte[] b) {
115         String hs = "";
116         String stmp = "";
117
118         for (int n = 0; n < b.length; n++) {
119             stmp = (java.lang.Integer.toHexString(b[n] & 0XFF));
120             if (stmp.length() == 1)
121                 hs = hs + "0" + stmp;
122             else
123                 hs = hs + stmp;
124             if (n < b.length - 1)
125                 hs = hs + " ";
126         }
127         return hs.toUpperCase();
128     }
129
130 }
131

acooly 2008-05-23 23:21 发表评论

对称加密和非对称加密

acooly — Wed, 21 May 2008 08:42:00 GMT

对称加密算法

JAVA-API部分算法实现

对称加密算法对称加密算法是应用较早的加密算法，技术成熟。在对称加密算法中，数据发信方将明文（原始数据）和加密密钥一起经过特殊加密算法处理后，使其变成复杂的加密密文发送出去。收信方收到密文后，若想解读原文，则需要使用加密用过的密钥及相同算法的逆算法对密文进行解密，才能使其恢复成可读明文。在对称加密算法中，使用的密钥只有一个，发收信双方都使用这个密钥对数据进行加密和解密，这就要求解密方事先必须知道加密密钥。对称加密算法的特点是算法公开、计算量小、加密速度快、加密效率高。不足之处是，交易双方都使用同样钥匙，安全性得不到保证。此外，每对用户每次使用对称加密算法时，都需要使用其他人不知道的惟一钥匙，这会使得发收信双方所拥有的钥匙数量成几何级数增长，密钥管理成为用户的负担。对称加密算法在分布式网络系统上使用较为困难，主要是因为密钥管理困难，使用成本较高。在计算机专网系统中广泛使用的对称加密算法有DES和IDEA等。美国国家标准局倡导的AES即将作为新标准取代DES。

DES

数据加密算法（Data Encryption Algorithm，DEA）的数据加密标准（Data Encryption Standard，DES）是规范的描述，它出自 IBM 的研究工作，并在 1997 年被美国政府正式采纳。它很可能是使用最广泛的秘钥系统，特别是在保护金融数据的安全中，最初开发的 DES 是嵌入硬件中的。通常，自动取款机（Automated Teller Machine，ATM）都使用 DES。
DES 使用一个 56 位的密钥以及附加的 8 位奇偶校验位，产生最大 64 位的分组大小。这是一个迭代的分组密码，使用称为 Feistel 的技术，其中将加密的文本块分成两半。使用子密钥对其中一半应用循环功能，然后将输出与另一半进行“异或”运算；接着交换这两半，这一过程会继续下去，但最后一个循环不交换。DES 使用 16 个循环。
攻击 DES 的主要形式被称为蛮力的或彻底密钥搜索，即重复尝试各种密钥直到有一个符合为止。如果 DES 使用 56 位的密钥，则可能的密钥数量是 2 的 56 次方个。随着计算机系统能力的不断发展，DES 的安全性比它刚出现时会弱得多，然而从非关键性质的实际出发，仍可以认为它是足够的。不过，DES 现在仅用于旧系统的鉴定，而更多地选择新的加密标准 — 高级加密标准（Advanced Encryption Standard，AES）。
DES 的常见变体是三重 DES，使用 168 位的密钥对资料进行三次加密的一种机制；它通常（但非始终）提供极其强大的安全性。如果三个 56 位的子元素都相同，则三重 DES 向后兼容 DES。
IBM 曾对 DES 拥有几年的专利权，但是在 1983 年已到期，并且处于公有范围中，允许在特定条件下可以免除专利使用费而使用。
由于DES是加(解)密64位明(密)文，即为8个字节(8*8=64)，可以据此初步判断这是分组加密，加密的过程中会有16次循环与密钥置换过程，据此可以判断有可能是用到DES密码算法，更精确的判断还得必须懂得一点DES的加密过程。

3DES

3DES是DES加密算法的一种模式，它使用3条64位的密钥对数据进行三次加密。数据加密标准（DES）是美国的一种由来已久的加密标准，它使用对称密钥加密法，并于1981年被ANSI组织规范为ANSI X.3.92。DES使用56位密钥和密码块的方法，而在密码块的方法中，文本被分成64位大小的文本块然后再进行加密。比起最初的DES，3DES更为安全。
3DES（即Triple DES）是DES向AES过渡的加密算法（1999年，NIST将3-DES指定为过渡的加密标准），是DES的一个更安全的变形。它以DES为基本模块，通过组合分组方法设计出分组加密算法，其具体实现如下：设Ek()和Dk()代表DES算法的加密和解密过程，K代表DES算法使用的密钥，P代表明文，C代表密表，这样，
3DES加密过程为：C=Ek3(Dk2(Ek1(P)))
3DES解密过程为：P=Dk1((EK2(Dk3(C)))

AES——对称密码新标准

对称密码体制的发展趋势将以分组密码为重点。分组密码算法通常由密钥扩展算法和加密（解密）算法两部分组成。密钥扩展算法将b字节用户主密钥扩展成r个子密钥。加密算法由一个密码学上的弱函数f与r个子密钥迭代r次组成。混乱和密钥扩散是分组密码算法设计的基本原则。抵御已知明文的差分和线性攻击，可变长密钥和分组是该体制的设计要点。

AES是美国国家标准技术研究所NIST旨在取代DES的21世纪的加密标准。

AES的基本要求是，采用对称分组密码体制，密钥长度的最少支持为128、192、256，分组长度128位，算法应易于各种硬件和软件实现。1998年 NIST开始AES第一轮分析、测试和征集，共产生了15个候选算法。1999年3月完成了第二轮AES2的分析、测试。预计在2000年8月AES的最终结果将公布。

在应用方面，尽管DES在安全上是脆弱的，但由于快速DES芯片的大量生产，使得DES仍能暂时继续使用，为提高安全强度，通常使用独立密钥的三级DES。但是DES迟早要被AES代替。流密码体制较之分组密码在理论上成熟且安全，但未被列入下一代加密标准。

非对称加密算法

asymmetric encoding algorithm
非对称加密算法需要两个密钥：公开密钥（publickey）和私有密钥（privatekey）。公开密钥与私有密钥是一对，如果用公开密钥对数据进行加密，只有用对应的私有密钥才能解密；如果用私有密钥对数据进行加密，那么只有用对应的公开密钥才能解密。因为加密和解密使用的是两个不同的密钥，所以这种算法叫作非对称加密算法。非对称加密算法实现机密信息交换的基本过程是：甲方生成一对密钥并将其中的一把作为公用密钥向其它方公开；得到该公用密钥的乙方使用该密钥对机密信息进行加密后再发送给甲方；甲方再用自己保存的另一把专用密钥对加密后的信息进行解密。甲方只能用其专用密钥解密由其公用密钥加密后的任何信息。非对称加密算法的保密性比较好，它消除了最终用户交换密钥的需要。

RSA算法演示

对称和非对称加密算法案例

基于多级密钥管理体系中的对称密钥传输保护方法

申请号/专利号： 200610147335

一种基于在多级密钥管理体系中的对称密钥传输保护方法，其步骤为：
１．传入方签发并通过两条途径传递两张密钥传输卡，每张卡中存有一段传入方的根公钥；
２．传出方从两张卡获得传入方的根公钥，并随机生成传输密钥，再用该根公钥加密后分段写入到两张卡中，其工作密钥用传输密钥传出并写入两张卡中通过两条途径递送给传入方；
３．传入方验证卡的合法性；从两张卡中获得传输密钥和工作密钥密文并用根私钥解密传输密钥写入加密机传输密钥区；传入方将工作密钥密文通过传输密钥写入工作密钥区，从而完成了两台密钥管理加密机之间的密钥传递过程。本发明采用证书方式，加强了对称密钥传输时的安全性，采用ＩＣ卡作为介质，保证了传输介质的安全。

申请日：	2006年12月15日
公开日：	2007年06月06日
授权公告日：
申请人/专利权人：	上海格尔软件股份有限公司
申请人地址：	上海市闸北区余姚路288号A座4层
发明设计人：	张翔;杨茂江;李澜涛
专利代理机构：
代理人：	陈学雯
专利类型：	发明专利
分类号：	H04L9/32;H04L9/14;H04L9/12;H04L9/08;H04L9/30

acooly 2008-05-21 16:42 发表评论

开发小经验汇总

acooly — Mon, 17 Sep 2007 03:30:00 GMT

1.回车转换行：onkeypress="if(event.keyCode == 13){//do script!}
2.Tomcat-linux环境图形显示问题：JAVA_OPTS="$JAVA_OPTS -Djava.awt.headless=true"
3.Eclipse启动参数：D:\eclipse3.2\eclipse.exe -data D:\workspace -product com.genuitec.myeclipse.product.ide -vmargs -Duser.language=en -Xms128M -Xmx512M -XX:PermSize=256M -XX:MaxPermSize=512M
4.eclipse生成javadoc乱码解决：加入参数“-encoding UTF-8 -charset UTF-8”
5.jsp页面禁止缓存代码：
    response.setHeader("Pragma","No-cache");
    response.setHeader("Cache-Control","no-cache");
    response.setDateHeader("Expires", 0);

6.linux－mount samba
   mount -t smbfs -o codepage=cp936 远程路径本地路径

7.查看端口对应PID
lsof -i tcp:PORT-NO, eg, lsof -i tcp:80
lsof -i udp:PORT-NO, eg, lsof -i udp:53

8.RH5.0下smbmount的代替方法
mount -t cifs //ip/f /location/dir ...

acooly 2007-09-17 11:30 发表评论

ORACLE 禁用/启用外键和触发器

acooly — Fri, 31 Aug 2007 02:45:00 GMT

Error convertoring HTML to XHTML: System.ArgumentException: Cannot have ']]>' inside an XML CDATA block. at System.Xml.XmlTextWriter.WriteCData(String text) at System.Xml.XmlWriter.WriteNode(XmlReader reader, Boolean defattr) at FreeTextBoxControls.Support.Formatter.HtmlToXhtml(String input)

acooly 2007-08-31 10:45 发表评论

基于角色的访问控制RBAC

acooly — Wed, 04 Jul 2007 04:10:00 GMT

1.概述

　　最近，随着电子商务和电子政务的发展，网络安全已成为研发的重点和热点。信息的完整性、机密性、身份鉴别和不可否认性构成了信息安全的四要素。非对称加密算法从理论和实践上都可以保证身份的有效性和不可否认性，而要保证软件系统、数据库和信息网络的完整性、和机密性，至今还没有一个行之有效的解决方案。如公司资源的讹误，信息的未授权泄漏或者失窃，以及被非法篡改都是因为没有保证信息的机密性和完整性而引起的。它们不仅破坏了组织的操作，并有可能涉及到金融，法律，人员安全，个人隐私和国家机密方面，而造成重大的损失。

　　当今最著名的美国计算机安全标准是可信计算机系统评估标准（TCSEC）。其中一个内容就是要阻止未被授权而浏览机密信息。TCSEC规定了两个访问控制类型：自主访问控制（DAC）和强制访问控制（MAC）。DAC是指主体可以自主地将访问权限或者访问权限的某个子集授予其他主体。主要是某些用户（特定客体的用户或具有指定特权的用户）规定别的用户能以怎样的方式访问客体。它主要满足商业和政府的安全需要，以及单级军事应用。但是由于它的控制是自主的，所以也可能会因为权限的传递而泄漏信息。另外，如果合法用户可以任意运行一个程序来修改他拥有的文件存取控制信息，而操作系统无法区分这种修改是用户自己的操作，还是恶意程序的非法操作，解决办法就是通过强加一些不可逾越的访问限制。因此，又提出了一种更强有力的访问控制手段，即强制访问控制（MAC），但是它主要用于多级安全军事应用，很少用于其他方面。现今人们在MAC基础上提出基于角色的访问控制（RBAC），它是一种强制访问控制形式，但它不是基于多级安全需求。其策略是根据用户在组织内部的角色制定的。用户不能任意的将访问权限传递给其他用户。这是RBAC和DAC之间最基本的不同。

　　基于角色访问控制（RBAC）模型是目前国际上流行的先进的安全访问控制方法。它通过分配和取消角色来完成用户权限的授予和取消，并且提供角色分配规则。安全管理人员根据需要定义各种角色，并设置合适的访问权限，而用户根据其责任和资历再被指派为不同的角色。这样，整个访问控制过程就分成两个部分，即访问权限与角色相关联，角色再与用户关联，从而实现了用户与访问权限的逻辑分离。

　　由于实现了用户与访问权限的逻辑分离，基于角色的策略极大的方便了权限管理。例如，如果一个用户的职位发生变化，只要将用户当前的角色去掉，加入代表新职务或新任务的角色即可。研究表明，角色/权限之间的变化比角色/用户关系之间的变化相对要慢得多，并且给用户分配角色不需要很多技术，可以由行政管理人员来执行，而给角色配置权限的工作比较复杂，需要一定的技术，可以由专门的技术人员来承担，但是不给他们给用户分配角色的权限，这与现实中的情况正好一致。

　　基于角色访问控制可以很好的描述角色层次关系，实现最小特权原则和职责分离原则。

　　2.RBAC的正式定义

　　基于角色访问控制（RBAC）的定义已经在第十五届国际计算机安全会议上以集合的形式给出。定义如下：

　　对于每一主体，激活角色是当前使用的主体：

　　AR（s：subject）={主体s的激活角色}

　　每一主体可被授权扮演一个或更多角色：

　　RA（s：subject）={主体s的授权角色}

　　每一角色可被授权执行一个或更多事务：

　　TA（r：role）={授权给角色r的事务}

　　主体可以执行事务。如果主体s可以在当前时间执行事务t，则预测exec（s，t）是真，否则为假：

　　exec(s: subject, t: tran) =true, 如果主体s可以执行事务t。

　　执行过程中的三个基本规则：

　　2.1 角色分配：仅当主体选择或被赋予一个角色，主体才能执行一个事务。

　　　

　　身份证明和鉴别过程（例如登录）不是一个事务。其他用户的所有在系统上的活动都可通过事务处理。因此要求所有激活用户具有某个激活角色。

　　2.2 角色授权：主体的激活角色必须是被授权的：
同上面的（1）一起，规则保证用户只能接收他们授予的角色。

　　2.3 事务授权：仅当事务被授权给主体激活角色时，主体才能执行该事务。

　　　

　　同（1）和（2）一起，本规则保证用户只可执行授权给他们的事务。注意，因为条件是“仅当（only if）”，本规则允许事务执行的出现附加限制的可能性。即，规则不保证一个事务只是因为它在TA(AR(s))中就是可执行的，TA(AR(s))是由主体激活角色执行的潜在事务集合。例如，一个主管角色的实习生可被赋予“主管”角色，但是在运用他/她用户角色时有限制，即对一主管可正常访问的子集，实习生可能受到限制。

　　上文中，“事务”的定义是变换过程（transformation procedure）加上一个由变换过程访问的数据项集。因为数据访问已被构建到事务中，所以上面规则的访问控制不要求对用户访问数据目标的权利或变换程序访问数据项的权利作任何检查。由于在设计阶段将操作和数据绑定为一个事务，所以存在安全性问题，例如此时的在保险查询事务中提出的个人隐私的问题。

　　当规则中“事务”只指变换程序时，需要重新定义“事务”的含义，即不包括对目标的绑定。若要实施方式控制则需要第四个规则，即在模型中用户通过事务程序访问目标。例如，利用事务（重新定义为变换程序），第四个规则可被定义为对象访问函数access(r, I, o, x)，

　　

　　它表明了是否允许角色r的主体利用事务t以x的方式来访问对象o，其中x是已经缩小的模式的集合。例如读，写，附加。

　　第四项规则可适用于医院配置。一位医生可被提供读/写药方的访问控制，而医院的药剂师可能只具有读的访问权力。（单独调用前三个规则，将事务过程t与t能访问的数据对象绑定在一块，并且只控制对事务的访问）。我们可以使用第四个规则替换，更有益于满足机密性的要求。

　　RBAC的另一个用途是支持完整性。完整性以几种不同的方式定义，但完整性的一个方面是要求数据和程序只能由授权用户以被授权的方式修改。这看起来对于很多真实的系统是一合理的安全目标，同时RBAC应适用于这样的系统。

　　一般来说，决定数据是否只以授权的方式修改的问题与修改事务是同样复杂的。由于这个原因，实际的方法是事务直接与另一事务合并。要求系统通过规则（4）中的访问函数控制事务程序对对象的访问，但是要取得完整性的同时需要极大的系统开销。因此，在RBAC中包含事务对对象的访问控制函数将在一些应用集中是有用的，但并不是所有的应用。

　　3.最小特权策略

　　最小特权原则对于满足完整性目标是非常重要的。最小特权原则要求用户只具有执行一项工作所必需的权限。要保证最小特权要求验证用户的工作是什么，要确定执行该项工作所要求的权限最小集合，并限制用户的权限域。若拒绝了不是主体职责的事务，则那些被拒绝的权限就不能绕过阻止安全性策略。尽管最小特权包含当前存在于TCSEC的内容当中，但仍限制系统管理员的权限。通过使用RBAC，很容易满足一般系统的用户执行最小权限。

　　4.职责分离

　　RBAC机制可被系统管理员用于执行职责分离的策略。职责分离对于反欺诈行为是非常有效的。它是在真实系统中最重要的想法。

　　职责分离或者是静态的，或者是动态的。符合静态职责分离要求职能由个人角色的分配和事务角色的分配决定的。最难的是动态职责分配，其中符合动态职责分离的职能在系统操作期间决定。动态职责分离目的是允许操作更灵活。

　　根据角色分配访问权利在定义职责分离上也是有帮助的，它由系统执行。

　　5.结论

　　虽然商业和政府组织中很多终端用户能够访问信息，但他们都不“拥有”信息。而这些组织机构恰恰是实际系统对象的“拥有者”，并且自主访问控制是不可能适合的。基于角色访问控制（RBAC）是一个非自主访问控制机制，它允许促进组织具体安全策略的中央管理。
访问控制决策通常基于角色，个人用户采取的角色作为组织的组成。一个角色规定了一个事务集合，即用户或用户集合可在组织内执行。RBAC提供命名和描述个人和权利之间的关系的方法，提供很多商业和政府组织需要的安全处理方法。

　　本文提到的基于角色访问控制（RBAC）的定义，已经在第十五届国际计算机安全会议上以集合的形式给出。本文的目的是让更多热爱网络安全的朋友了解RBAC，使这一新型的访问控制方案得到更多的应用。

acooly 2007-07-04 12:10 发表评论