2008年03月
前段时间利用数字证书对几种语言（Java、.Net、Php） 调用WS-Security支持的Web Service进行了联调测试，在这个过程中各语言需要的证书格式并不一致，比如说Java我们采用jks，.Net采用pfx和cer，Php则采用pem和cer；本文会对Security证书相关各类文件格式进行一个汇总，并描述各种格式的适用场景；主要分成两类，其一为密钥库文件格式、其二为证书文件格式；阅读全文>
发表于 @ 2008年03月31日 17:59:00|评论(loading...)|编辑
目前在PHP中调用带有WS-Security支持的Web Service解决方案还是比较少的，WSF/PHP是一个不错的选择，官方首页为http://wso2.org/projects/wsf/php，下面就介绍下在运用WSF/PHP的时候需要注意的一些地方；
阅读全文>
发表于 @ 2008年03月29日 17:06:00|评论(loading...)|编辑
针对不同的.Net SDK版本有三种实现来满足对带有WS-Security支持的Web Service调用，即WSE 2.0、WSE 3.0、WCF【Windows Communication Foundation】；其中WSE 2.0针对的是VS 2003版本，WSE 3.0针对的是VS 2005版本，WCF针对的是VS 2008，从SDK要求来看，WSE 2.0和3.0是2.0，而WCF要求是3.0或3.5；前面我的同事已经将WSE 2.0调通，但是对WSE 3.0始终无法调通，具体可以参见《Web Service 、WS-Security、Java和.net的互通(在路上-基于SCA规范的应用服务框架成长记之四》；而WCF经过微软研究院几个月的调试，也已经调通，具体可以参见《.Net在Alibaba的AEP平台上的应用》；不幸的是，针对这两种配置方案经测试是不兼容的，因为不止是.Net客户端调整配置和代码，Java服务端仍然要做出调整，这对于我们的系统侵入是非常大的，因为现在已经有ISV采用WSE 2.0实现在生产环境运行了，要想在服务端做出调整的话必须要做到无缝升级，也即线上所阅读全文>
发表于 @ 2008年03月25日 17:53:00|评论(loading...)|编辑
客户端默认开启了enableSignatureConfirmation标识，这样客户端就需要验证ws返回的xml里面的wsse:SignatureConfirmation信息，而服务端却在axis2.xml中设置了false，服务端若设置为true，则要求请求的接收方确认响应中包括了来自请求的所有签名，否则验证不通过；客户端在验证服务端返回的xml有效性的时候要求：验证的顺序一定要和服务端设置一致；比如我们服务端对返回xml设置了Timestamp和Signature，那么客户端设置的InHandler中对应的action也必须是Timestamp和Signature，并且顺序要一致，否则就会验证不通过（这个在wss4j的mail list中有很多人认为这是一个bug，这个要求太强制了，wss4j也承诺后续将这个实现也改掉）；X509KeyIdentifier, DirectReference两者是将证书信息直接暴露在请求的soap xml中；而其他三者只保存对证书的标识性信息，接收端可以根据这些信息到证书库中取出具体的证书来进行相应的操作；阅读全文>
发表于 @ 2008年03月20日 20:42:00|评论(loading...)|编辑
1、专利无大小、简单复杂之分，与其市场价值有关
2、专利申请遵循三大原则：市场原则、技术原则、成本原则
3、针对技术人员，要淡化创造性思考
4、速度要快
5、专利的抽象程度尽可能低，控制粒度阅读全文>
发表于 @ 2008年03月18日 10:08:00|评论(loading...)|编辑
.Net环境下每次用RSA算法加密都会得到不同的结果，这是因为每次都添加了一些随机数，其实这些随机数的生成也是遵循算法标准的，更专业的说是随机填充算法，比如NoPadding、ISO10126Padding、OAEPPadding、PKCS1Padding、PKCS5Padding、SSL3Padding，而最常见的应该是OAEPPadding【Optimal Asymmetric Encryption Padding】、PKCS1Padding；.Net的实现用的是PKCS1Padding，而且只有这一种实现，也不能通过参数指定用哪种填充算法；另外，通过RSACryptoServiceProvider.KeyExchangeAlgorithm查看到的结果是RSA-PKCS1-KeyEx，由于无法看到源码，不知道最后的KeyEx代表什么意思？阅读全文>
发表于 @ 2008年03月16日 21:31:00|评论(loading...)|编辑
RFC可以译为【请求注解】；他包含了关于Internet的几乎所有重要的文字资料。通常，当某家机构或团体开发出了一套标准或提出对某种标准的设想，想要征询外界的意见时，就会在Internet上发放一份RFC，对这一问题感兴趣的人可以阅读该RFC并提出自己的意见；绝大部分网络标准的指定都是以RFC的形式开始，经过大量的论证和修改过程，由主要的标准化组织所指定的，但在RFC中所收录的文件并不都是正在使用或为大家所公认的，也有很大一部分只在某个局部领域被使用或并没有被采用，一份RFC具体处于什么状态都在文件中作了明确的标识。现在通过RFC发布标准的组织已经很多了，比如IETF、IAB、ISO、ANSI、ITU等等；
PKCS是由美国RSA数据安全公司及其合作伙伴制定的一组公钥密码学标准，其中包括证书申请、证书更新、证书作废表发布、扩展证书内容以及数字签名、数字信封的格式等方面的一系列相关协议。
X.509是由ITU-T为证书及其CRL格式提供了一个标准；但X.509本身不是Internet标准（因为不是由IETF制定），它定义了一个开放的框架，并在一定的范围内可以进行扩展。
其实ITU阅读全文>
发表于 @ 2008年03月13日 16:11:00|评论(loading...)|编辑
私钥加密是可以用公钥解密的；所以说对于RSA算法，用任何一方密钥加密都可以用另外一个密钥解密；这也从另外一个角度说明，其实公钥和私钥是相对而言的，发放其中一个密钥出去，另外一个自然也就成为私钥了；
数字签名包括4个步骤：消息散列，DER数据编码，RSA私钥加密和字节串到位串的转换。
数字签名的验证过程包括四个步骤：位串到字节串的转换，RSA公钥解密，DER数据解码，得到解密后的散列值，最后与原始数据散列值进行比较，若每一位都相同则返回true，否则返回false；阅读全文>
发表于 @ 2008年03月12日 20:06:00|评论(loading...)|编辑
.Net环境下面对同样一个字符串用相同的RSA公钥加密，居然每次的结果不一样！而Java环境下面则每次的结果是一样的；这点就是我们此次解决互通问题的关键！究其原因是这样的：.Net为了加强RSA加密算法的安全性，在每次加密的时候都会生成一定的随机数和原始数据一起被加密，这显然不是单纯标准的RSA加密；而Java中的RSA加密是完全标准化的，不添加随机数的；这样双方的加密标准就是不一样的，所以一方加密另一方解密肯定是不能成功的啦！
阅读全文>
发表于 @ 2008年03月07日 15:59:00|评论(loading...)|编辑