- 浏览: 258770 次
- 性别:
- 来自: 深圳
最新评论
-
whizkid:
[img] private void enableNdefEx ...
android通过NFC读写数据 -
zhangminglife:
您好!不错,最近正在弄这个东西,能否把demo发给我一份谢谢了 ...
SSL双向认证java实现(转) -
water卡:
android如何调用显示和隐藏系统默认的输入法 -
water卡:
android如何调用显示和隐藏系统默认的输入法 -
sjp524617477:
good
生成android使用的BKS证书
金融行业因为对数据比较敏感,所以对数据的加密也相应的比较重视。在其中有关密钥及加密方面的文章很少,并且散发在各个银行及公司的手中,在网上没有专门对这部分进行介绍的。本文对金融行业的密钥进行较深入的介绍,包括象到底什么是主密钥(MasterKey)、传输密钥(MacKey),为什么我们需要这些东西等。
本文采取追源溯本的方式,力求让对这感兴趣的人达到知其然,同时也知其所以然,而不是模模糊糊的知道几个概念和名词。因为本文主要是针对对金融行业密钥不是很熟悉的人,所以如果你对密钥很熟悉就不必仔细看了。
好了,咱们言规正传。我们知道,金融行业有很多数据要在网络上传递,包括从前置到主机,从自助终端到前置等,这些数据在网络上传来传去,我们很容易就会想到安全性的问题,如果这些数据被人窃取或拦截下来,那我们怎么敢在银行存钱了。这个问题在计算机出现时就被前人考虑到了,所以出现了很多各种各样的加解密技术。
抛开这些不管,假设当初由我们自己来设计怎样解决数据被窃取的情况。假设我们有一段数据,是ATM取款的报文,包括一个人的磁卡号、密码、取款金额,现在需要将这些数据从一台ATM机器传到前置机处理,这些数据是比较机密的,如果被人窃取了,就可以用该卡号和密码把帐户中的钱取走。
首先,我们可以想到用专用的银行内部网络,外面的人无法获得网络的访问权。这个仔细想想显然不可行的,因为一是不能保证外人一定没办法进入银行内部网络,二是银行内部人员作案是没法防止的。
接着,我们很容易想到,既然保证数据不被窃取的可能性很小,那我们何不变换一下思路,数据避免不了被窃取,那我如果将数据处理下,让你即使窃取到数据,也是一些无用的乱码,这样不就解决问题了吗。这个想法比较接近现在的做法了,当前置机接收到了数据,它肯定是对数据进行反处理,即与ATM端完全步骤相反的数据处理,即可得到明文的数据。我们再进一步想想,如果因为某种原因,报文中的取款金额被改变了,这样就会导致ATM出的钱和前置扣帐记录的钱不一致的情况,看来我们必须加上一个验证机制,当前置机收到ATM发送的一个报文时,能够确认报文中的数据在网络传输过程中没有被更改过。
怎样实现?最简单的,象计算机串口通讯一样,对通讯数据每一位进行异或,得到0或1,把0或1放在在通讯数据后面,算是加上一个奇偶校验位,收到数据同样对数据每位进行异或,得到0或1,再判断下收到数据最后一位与算出来的是否一致。这种方式太简单了,对于上面提到的ATM到前置机的报文来说,没什么用处,不过我们可以将对数据每一位异或的算法改成一个比较复杂点的。
因为DES算法已经出来了很多年了,并且在金融行业也有广泛的应用,我们何不用DES算法进行处理,来解决上面的问题呢。我们应该了解DES算法(此处指单DES)的,就是用一个64bit 的Key对64bit的数据进行处理,得到加密后的64bit数据。那我们用一个Key对上面的报文进行DES算法,得到加密后的64bit数据,放到报文的最后,跟报文一起送到前置机,前置机收到报文后,同样用Key对数据(不包括最后的64bit加密数据)进行DES加密,得出64bit的数据,用该数据与ATM发送过来的报文最后的64bit数据比较,如果两个数据相同,说明报文没有中途被更改过。
再进一步,因为DES只能够对64bit的数据进行加密,一个报文可不止64bit,哪我们怎么处理呢?只对报文开头的64bit加密?这个是显然不够的。
我们可以这样,先对报文的开始64bit加密,接着对报文第二个64bit加密,依次类推,不过这有问题,因为每个64bit都会得到同样长度的加密后的数据,我不能把这些数据都放到报文的后面,那报文的长度不变成两倍长了。换个思路,我先对报文第一个64bit加密,得到64bit的加密后数据data1,接着再拿加密后的data1与报文第二个64bit数据进行按位异或,得到同样长64bit的数据data2,我再用Key对data2加密,得到加密后的数据data3,再拿data3与报文第三个64bit数据进行按位异或,同样的处理依次类推。直到最后会得到一个64bit的数据,将这个数据放到报文的最后发到前置机,这样报文的长度只增加了64bit而已。这个算法就叫做MAC算法。
好了,到目前为止我们已经知道了什么是MAC算法,为什么需要它,接着我们再看看经常被提起的另外一个名词。在上面说到MAC算法的时候,我们会注意到其中进行DES加密算法时提到了一个Key,这个用来参与MAC计算的Key就常被称为MacKey,也有叫工作密钥、过程密钥的。
我们继续来处理ATM和前置机间网络数据传输的问题。前面提到的MAC算法对传送的报文进行了处理,保证了在网络传输过程中数据不会被有意或无意的篡改,但是,我们再进一步想想,如果仍然是上面提到的一个取款报文,如果想作案的话,我不改报文的内容,我只是截取报文的内容,因为内容里面有卡号和密码,都是明文的形式,很容易就看出来哪些内容是卡号、哪些内容是密码。有了卡号和密码,我就好办了,找个读卡器就能够很快的制出一张磁卡,然后拿这个磁卡可以随便取钱了,根本不需要修改报文,这样你就算前置机对报文的MAC校验通过了,也只是保证了报文没改动过,对于防止作案没有实质上的帮助。
那我们很容易想到,我再加上一道加密,这次我把整个存款的报文都用DES加密,将明文全部转换成密文,然后送到前置机,这下好了吧。即使你把报文截取了也没用,你拿着这些密文也没有用,你也没有DES的密钥来解密它,只有前置机才知道密钥。这是个好主意,确实防止了卡号和密码等被人获知的危险。这也是现在普遍采取的做法,不过我们需要对这个做法进行一些改进。
首先,我们要知道用DES对数据加解密是耗时间的,尤其是使用硬加密(下一步讲什么是硬加密)的情况,速度是比较慢的。我们来想想,整个存款报文有必要每个数据都DES加密吗,象报文中的什么流水号、ATM号等信息,对它们加密没什么意义,进一步讲,取款金额加密也没意义,假设你取500块,但是你将报文改成了100块,导致主机只把你帐户扣100块钱,你白赚了400块。这个听起来挺划算的,实际上是不可行的,因为这样造成了帐务上的短款,银行当然会查账的,根据ATM记录的硬件出钞张数和主机扣款金额,肯定会把你查出来的,那这种掩耳盗铃的做法,下场显而易见,想必没人这么傻。
我们来考虑一个报文中到底什么信息是需要加密的,目前一般的做法是只对帐号和密码(也有只对密码加密的)进行加密,其他的内容不加密的,明文就明文,没什么大不了的。对帐号和密码加密有个术语,我们可能都听说过,叫PinBlock,即PIN块,就是对帐号和密码进行DES加密处理后的一个密文数据块。即然使用了DES算法来加密帐号和密码,则必然有个Key来加密,那么我们就把这个Key称为PinKey,就是专门来加密用户帐户和密码的Key。
至于怎样进行加密形成最后的密文PinBlock,有很多标准的,象IBM3624、ANSI、ISO、DIEBOLD等标准,其实它们大同小异,就是在对报文中的密码进行一个预处理,再用PinKey来DES加密,主要的差别就是怎样预处理而已,比如有的是密码后面补F,补够16位,就是类似这样的预处理。
到这里我们应该理解PinKey和PinBlock了。通过PinKey和MacKey对报文进行了两重处理,基本上报文就是安全的了。如果我们对DES算法比较了解,就会知道,如果想对加密后的密文解密,必须要知道Key才行,所以说Key一定要保密。怎样来保密Key呢?我们前面提到的无论是算MAC还是算PIN块,都是直接拿明文的Key来计算的,那么这个Key很容易被窃取的,比如有人在机器上装了个黑客程序,只要检测到你在用Key加密数据,就把明文的Key获取了。这个听起来好像挺玄乎的,不过是有这个可能性的,尤其是网上银行这些东东最容易中招了。
这样看来,我们还要对PinKey和MacKey本身进行加密,不要让人知道了。怎样实现,同样是DES算法大显身手的地方。我再找个Key对PinKey和MacKey进行一次加密,这样你就看不到PinKey和MacKey的明文了,好,解决问题了。这时用来对PinKey和MacKey进行加密的Key就被我们称为MasterKey,即主密钥,用来加密其他密钥的密钥。不过,需要等一下,那MasterKey怎么办,它是明文啊。再找个Key来加密MasterKey,那最终无论处理多少道,最后的那个Key肯定是明文,这样看来,安全的问题还没有解决啊。
既然此路不通,那我们需要换个思维角度了,仔细想想怎样处理明文的MasterKey。黑客程序只能窃取我软件上的东西,如果我把MasterKey放到硬件里面怎么样,黑客是没能力跑到我硬件里面把MasterKey取出来的,当然,不排除道高一尺、魔高一丈的情况,但至少99.9%的黑客都没这能力的。那这样不就解决了我们遇到的问题了吗,只要把MasterKey放到硬件里面(一般是键盘的加密模块里面)就好了。
好,到这里,我们已经不怕有人把报文中的关键信息获取到了,总算是安全了。
在最近,老是有人提到“硬加密”,这个有什么用呢?我上面不是已经解决了加密的问题了吗,还要这个概念干什么?看来我还是有些地方没考虑到。我一直想的是将明文的密码加密成密文,其中有个环节需要考虑下,明文的密码是怎样形成的,不就是我按键盘上面的数字形成的吗。以前我的软件处理是这样的,键盘每按一下,我就把那个数字在程序里面先存起来,等到4位或6位密码按完后,再把它们合在一起,再送给PinKey加密。那如果黑客程序直接把我的按键信息获取,那他根本不用破解报文中用PinKey加密后的密码,直接简单的就把我输入的密码得到了,我前面费尽心思对密码进行加密处理变得一点意义都没有了。
怎么办?如果我把获取按键的程序固化进入加密硬件(一般在键盘中),按键的数字根本不通过上层的软件,直接一步进入硬件里面处理,等到按键按完了后,硬件直接把经过一道处理的按键信息给我上层软件,此时已经是密文了,就相当于把前面计算PinBlock的处理移到硬件里面去了,那黑客就没法获取我的按键了。这种处理现在就被称为硬加密,伴随着EMV和3DES算法,变得越来越流行了,好像自助终端不支持硬加密就不行,连EMV也强制要求了。
最近还有个名词经常被提到,就是3DES。为什么要提出3DES的概念呢?我在一篇文章中提到了3 DES的具体算法,其实推出3DES是因为原来的单DES算法随着计算机硬件的速度提升,存在被破解的可能性,所以将算法进行了改进,改为3DES算法。但是对于我们理解金融行业的密钥及加密机制来说,用什么算法都一样。不同算法的差别只是怎样对数据进行移位变换等具体处理而已。
对于ATM交易安全性的考虑问题,系统通过pin加密,MAC效验来保证系统交易数据的合法性及完整性,PIN BLOCK产生,PIN加密,MAC效验都可在ATM的加密键盘进行。
以下简单解释概念:
1.工作密钥(WK)PIN Key:持卡人密码的加密传输(TPK,ZPK,PVK)
2.MAC Key:用于交易报文的鉴别,保证数据完整性(TAK, ZAK)
3.COM Key: 用于交易报文的通讯加密/解密(TEK,ZEK)
4.密钥交换密钥(KEK)Zone Master Key:节点间交换工作密钥时加密保护(ZMK)
5.Terminal Master Key:用于主机与金融终端交换工作密钥(TMK)
6.本地主密钥(LMK)Local Master Key:用于加密存储其它密钥
系统密钥的管理是保证整个系统交易安全的关键,三级密钥管理体系:
LMK(本地主密钥) 最高层密钥,用于加密TMK,ZMK
TMK(终端主密钥),ZMK(区域主密钥) 交换密钥,用于加密PIN KEY
MAC KEY,COM KEY
PIN KEY,MAC KEY,COM KEY PIN KEY用于加密密码
工作密钥 MAC KEY 用于效验报文
COM KEY 用于通讯加密
本文采取追源溯本的方式,力求让对这感兴趣的人达到知其然,同时也知其所以然,而不是模模糊糊的知道几个概念和名词。因为本文主要是针对对金融行业密钥不是很熟悉的人,所以如果你对密钥很熟悉就不必仔细看了。
好了,咱们言规正传。我们知道,金融行业有很多数据要在网络上传递,包括从前置到主机,从自助终端到前置等,这些数据在网络上传来传去,我们很容易就会想到安全性的问题,如果这些数据被人窃取或拦截下来,那我们怎么敢在银行存钱了。这个问题在计算机出现时就被前人考虑到了,所以出现了很多各种各样的加解密技术。
抛开这些不管,假设当初由我们自己来设计怎样解决数据被窃取的情况。假设我们有一段数据,是ATM取款的报文,包括一个人的磁卡号、密码、取款金额,现在需要将这些数据从一台ATM机器传到前置机处理,这些数据是比较机密的,如果被人窃取了,就可以用该卡号和密码把帐户中的钱取走。
首先,我们可以想到用专用的银行内部网络,外面的人无法获得网络的访问权。这个仔细想想显然不可行的,因为一是不能保证外人一定没办法进入银行内部网络,二是银行内部人员作案是没法防止的。
接着,我们很容易想到,既然保证数据不被窃取的可能性很小,那我们何不变换一下思路,数据避免不了被窃取,那我如果将数据处理下,让你即使窃取到数据,也是一些无用的乱码,这样不就解决问题了吗。这个想法比较接近现在的做法了,当前置机接收到了数据,它肯定是对数据进行反处理,即与ATM端完全步骤相反的数据处理,即可得到明文的数据。我们再进一步想想,如果因为某种原因,报文中的取款金额被改变了,这样就会导致ATM出的钱和前置扣帐记录的钱不一致的情况,看来我们必须加上一个验证机制,当前置机收到ATM发送的一个报文时,能够确认报文中的数据在网络传输过程中没有被更改过。
怎样实现?最简单的,象计算机串口通讯一样,对通讯数据每一位进行异或,得到0或1,把0或1放在在通讯数据后面,算是加上一个奇偶校验位,收到数据同样对数据每位进行异或,得到0或1,再判断下收到数据最后一位与算出来的是否一致。这种方式太简单了,对于上面提到的ATM到前置机的报文来说,没什么用处,不过我们可以将对数据每一位异或的算法改成一个比较复杂点的。
因为DES算法已经出来了很多年了,并且在金融行业也有广泛的应用,我们何不用DES算法进行处理,来解决上面的问题呢。我们应该了解DES算法(此处指单DES)的,就是用一个64bit 的Key对64bit的数据进行处理,得到加密后的64bit数据。那我们用一个Key对上面的报文进行DES算法,得到加密后的64bit数据,放到报文的最后,跟报文一起送到前置机,前置机收到报文后,同样用Key对数据(不包括最后的64bit加密数据)进行DES加密,得出64bit的数据,用该数据与ATM发送过来的报文最后的64bit数据比较,如果两个数据相同,说明报文没有中途被更改过。
再进一步,因为DES只能够对64bit的数据进行加密,一个报文可不止64bit,哪我们怎么处理呢?只对报文开头的64bit加密?这个是显然不够的。
我们可以这样,先对报文的开始64bit加密,接着对报文第二个64bit加密,依次类推,不过这有问题,因为每个64bit都会得到同样长度的加密后的数据,我不能把这些数据都放到报文的后面,那报文的长度不变成两倍长了。换个思路,我先对报文第一个64bit加密,得到64bit的加密后数据data1,接着再拿加密后的data1与报文第二个64bit数据进行按位异或,得到同样长64bit的数据data2,我再用Key对data2加密,得到加密后的数据data3,再拿data3与报文第三个64bit数据进行按位异或,同样的处理依次类推。直到最后会得到一个64bit的数据,将这个数据放到报文的最后发到前置机,这样报文的长度只增加了64bit而已。这个算法就叫做MAC算法。
好了,到目前为止我们已经知道了什么是MAC算法,为什么需要它,接着我们再看看经常被提起的另外一个名词。在上面说到MAC算法的时候,我们会注意到其中进行DES加密算法时提到了一个Key,这个用来参与MAC计算的Key就常被称为MacKey,也有叫工作密钥、过程密钥的。
我们继续来处理ATM和前置机间网络数据传输的问题。前面提到的MAC算法对传送的报文进行了处理,保证了在网络传输过程中数据不会被有意或无意的篡改,但是,我们再进一步想想,如果仍然是上面提到的一个取款报文,如果想作案的话,我不改报文的内容,我只是截取报文的内容,因为内容里面有卡号和密码,都是明文的形式,很容易就看出来哪些内容是卡号、哪些内容是密码。有了卡号和密码,我就好办了,找个读卡器就能够很快的制出一张磁卡,然后拿这个磁卡可以随便取钱了,根本不需要修改报文,这样你就算前置机对报文的MAC校验通过了,也只是保证了报文没改动过,对于防止作案没有实质上的帮助。
那我们很容易想到,我再加上一道加密,这次我把整个存款的报文都用DES加密,将明文全部转换成密文,然后送到前置机,这下好了吧。即使你把报文截取了也没用,你拿着这些密文也没有用,你也没有DES的密钥来解密它,只有前置机才知道密钥。这是个好主意,确实防止了卡号和密码等被人获知的危险。这也是现在普遍采取的做法,不过我们需要对这个做法进行一些改进。
首先,我们要知道用DES对数据加解密是耗时间的,尤其是使用硬加密(下一步讲什么是硬加密)的情况,速度是比较慢的。我们来想想,整个存款报文有必要每个数据都DES加密吗,象报文中的什么流水号、ATM号等信息,对它们加密没什么意义,进一步讲,取款金额加密也没意义,假设你取500块,但是你将报文改成了100块,导致主机只把你帐户扣100块钱,你白赚了400块。这个听起来挺划算的,实际上是不可行的,因为这样造成了帐务上的短款,银行当然会查账的,根据ATM记录的硬件出钞张数和主机扣款金额,肯定会把你查出来的,那这种掩耳盗铃的做法,下场显而易见,想必没人这么傻。
我们来考虑一个报文中到底什么信息是需要加密的,目前一般的做法是只对帐号和密码(也有只对密码加密的)进行加密,其他的内容不加密的,明文就明文,没什么大不了的。对帐号和密码加密有个术语,我们可能都听说过,叫PinBlock,即PIN块,就是对帐号和密码进行DES加密处理后的一个密文数据块。即然使用了DES算法来加密帐号和密码,则必然有个Key来加密,那么我们就把这个Key称为PinKey,就是专门来加密用户帐户和密码的Key。
至于怎样进行加密形成最后的密文PinBlock,有很多标准的,象IBM3624、ANSI、ISO、DIEBOLD等标准,其实它们大同小异,就是在对报文中的密码进行一个预处理,再用PinKey来DES加密,主要的差别就是怎样预处理而已,比如有的是密码后面补F,补够16位,就是类似这样的预处理。
到这里我们应该理解PinKey和PinBlock了。通过PinKey和MacKey对报文进行了两重处理,基本上报文就是安全的了。如果我们对DES算法比较了解,就会知道,如果想对加密后的密文解密,必须要知道Key才行,所以说Key一定要保密。怎样来保密Key呢?我们前面提到的无论是算MAC还是算PIN块,都是直接拿明文的Key来计算的,那么这个Key很容易被窃取的,比如有人在机器上装了个黑客程序,只要检测到你在用Key加密数据,就把明文的Key获取了。这个听起来好像挺玄乎的,不过是有这个可能性的,尤其是网上银行这些东东最容易中招了。
这样看来,我们还要对PinKey和MacKey本身进行加密,不要让人知道了。怎样实现,同样是DES算法大显身手的地方。我再找个Key对PinKey和MacKey进行一次加密,这样你就看不到PinKey和MacKey的明文了,好,解决问题了。这时用来对PinKey和MacKey进行加密的Key就被我们称为MasterKey,即主密钥,用来加密其他密钥的密钥。不过,需要等一下,那MasterKey怎么办,它是明文啊。再找个Key来加密MasterKey,那最终无论处理多少道,最后的那个Key肯定是明文,这样看来,安全的问题还没有解决啊。
既然此路不通,那我们需要换个思维角度了,仔细想想怎样处理明文的MasterKey。黑客程序只能窃取我软件上的东西,如果我把MasterKey放到硬件里面怎么样,黑客是没能力跑到我硬件里面把MasterKey取出来的,当然,不排除道高一尺、魔高一丈的情况,但至少99.9%的黑客都没这能力的。那这样不就解决了我们遇到的问题了吗,只要把MasterKey放到硬件里面(一般是键盘的加密模块里面)就好了。
好,到这里,我们已经不怕有人把报文中的关键信息获取到了,总算是安全了。
在最近,老是有人提到“硬加密”,这个有什么用呢?我上面不是已经解决了加密的问题了吗,还要这个概念干什么?看来我还是有些地方没考虑到。我一直想的是将明文的密码加密成密文,其中有个环节需要考虑下,明文的密码是怎样形成的,不就是我按键盘上面的数字形成的吗。以前我的软件处理是这样的,键盘每按一下,我就把那个数字在程序里面先存起来,等到4位或6位密码按完后,再把它们合在一起,再送给PinKey加密。那如果黑客程序直接把我的按键信息获取,那他根本不用破解报文中用PinKey加密后的密码,直接简单的就把我输入的密码得到了,我前面费尽心思对密码进行加密处理变得一点意义都没有了。
怎么办?如果我把获取按键的程序固化进入加密硬件(一般在键盘中),按键的数字根本不通过上层的软件,直接一步进入硬件里面处理,等到按键按完了后,硬件直接把经过一道处理的按键信息给我上层软件,此时已经是密文了,就相当于把前面计算PinBlock的处理移到硬件里面去了,那黑客就没法获取我的按键了。这种处理现在就被称为硬加密,伴随着EMV和3DES算法,变得越来越流行了,好像自助终端不支持硬加密就不行,连EMV也强制要求了。
最近还有个名词经常被提到,就是3DES。为什么要提出3DES的概念呢?我在一篇文章中提到了3 DES的具体算法,其实推出3DES是因为原来的单DES算法随着计算机硬件的速度提升,存在被破解的可能性,所以将算法进行了改进,改为3DES算法。但是对于我们理解金融行业的密钥及加密机制来说,用什么算法都一样。不同算法的差别只是怎样对数据进行移位变换等具体处理而已。
对于ATM交易安全性的考虑问题,系统通过pin加密,MAC效验来保证系统交易数据的合法性及完整性,PIN BLOCK产生,PIN加密,MAC效验都可在ATM的加密键盘进行。
以下简单解释概念:
1.工作密钥(WK)PIN Key:持卡人密码的加密传输(TPK,ZPK,PVK)
2.MAC Key:用于交易报文的鉴别,保证数据完整性(TAK, ZAK)
3.COM Key: 用于交易报文的通讯加密/解密(TEK,ZEK)
4.密钥交换密钥(KEK)Zone Master Key:节点间交换工作密钥时加密保护(ZMK)
5.Terminal Master Key:用于主机与金融终端交换工作密钥(TMK)
6.本地主密钥(LMK)Local Master Key:用于加密存储其它密钥
系统密钥的管理是保证整个系统交易安全的关键,三级密钥管理体系:
LMK(本地主密钥) 最高层密钥,用于加密TMK,ZMK
TMK(终端主密钥),ZMK(区域主密钥) 交换密钥,用于加密PIN KEY
MAC KEY,COM KEY
PIN KEY,MAC KEY,COM KEY PIN KEY用于加密密码
工作密钥 MAC KEY 用于效验报文
COM KEY 用于通讯加密
发表评论
-
PBOC规范研究之六、变长记录文件
2014-08-14 20:11 947PBOC规范研究之六、变长记录文件 此博文包含图片 (20 ... -
Windows桌面共享中一些常见的抓屏技术
2014-06-06 15:01 10821. BitBlt 我想做Windows开 ... -
error C2440 “static_cast” 无法从“void (__thiscall )(void)”转换为“LRESULT
2013-11-18 13:51 1571error C2440 “static_cast” 无法从 ... -
WOSA/XFS结构、背景等介绍
2013-11-14 13:28 1237前言: 写给 ... -
查看oracle用户数据库连接数
2013-10-30 12:31 686查看oracle用户数据库连接数 1、查询oracle的连接 ... -
几种穿透防火墙技术
2013-07-12 18:28 1026本人对几种穿透防火墙技术 以下是本人对几种穿透技术学习笔记和一 ... -
C# Socket编程笔记
2013-06-16 08:58 0看到这个题目,是不是 ... -
rdp delphi实现远程桌面
2012-11-11 00:17 76581. 首先确保你的机器上存在mstscax.dll,如果没有这 ... -
xml通配符
2012-11-09 09:33 2460解析xml字符串 < -> < &g ... -
cobol中常用的数据类型
2012-08-22 15:13 1283COBOL上的基本类型大致分为:常量、变量、直接数和结构体。下 ... -
(转)学习maven的使用,看到一篇很实用的入门教程(菜鸟级入门)
2012-07-12 15:19 866一、前言 早 ... -
NFC相关研究
2012-05-15 14:07 1166NFC概述 NFC是短距离的无线通信,通常距 ... -
Android 面试题
2012-05-15 14:05 992Android 面试题 经典 1、 Android dvm的进 ... -
使用Java实现CA
2012-04-11 14:31 939一. 准备 1. JDK 1.6 2. 安 ... -
Eclipse快捷键汇总
2012-03-20 10:39 824自动补齐类名 Alt+. 作用 ... -
SSL的工作流程简介(转)
2012-03-01 16:47 9631:客户端的浏览器向服务器传送客户端 SSL 协议的版本号,加 ... -
Http之Get/Post请求区别
2011-09-06 15:24 8991.HTTP请求格式: <request line> ... -
keystore提取私钥和证书
2011-07-19 10:46 2731keytool -genkey -alias test -ke ... -
Keytool命令行参数说明
2011-07-11 15:47 1167Keytool命令行参数说明 2010-03-19 17:05 ... -
如何用jdk的keytool制作ssl证书
2011-07-11 10:19 1725C=CN,OU=IT,O=YIXIUWANG,ST=BEIJI ...
相关推荐
总结以上所述,金融行业密钥详解一文深入探讨了金融行业中关于密钥的几个核心知识点,包括主密钥和传输密钥的概念、DES和MAC算法的应用,以及这些技术如何在实际中保障数据传输的安全性。通过上述内容,我们可以了解...
金融行业密钥详解主要涉及主密钥(MasterKey)和传输密钥(MacKey)的概念及其作用。由于金融数据的高度敏感性,加密技术在保护数据安全中扮演着至关重要的角色。 首先,主密钥(MasterKey)是密钥体系的核心,通常...
"银联8583报文"是指银联网络中使用的标准报文格式,它是金融行业间通信的一种规范。8583报文格式包含了交易的各种信息,如交易类型、金额、账户信息等,并且使用主密钥进行加解密,确保数据在传输过程中的安全性。...
- **金融交易**:在金融行业中,大量的数据交换都需要高度的安全保障,XML加密技术在这里发挥着重要作用。 ### 结论 虽然“xml密钥KET”这个概念在描述中提及到了破解XML文件的用途,但在实际应用中,我们应当遵循...
首先,TR31标准,全称为"Secure Key Import and Export (SKI)",是由澳大利亚的金融行业制定的一项技术规范,旨在提供一种安全可靠的方法,使金融机构能够通过不安全的通信渠道安全地导入和导出对称密钥。...
### 中国金融PSAM卡应用规范详解 #### 文件结构与安全性设计 中国金融PSAM(Payment System ...这不仅提升了金融交易的安全性,也促进了金融行业的标准化进程,对于推动我国金融电子化、智能化发展具有重要意义。
江南加密机(SJL06)是一款专门针对金融行业设计的安全加密设备,主要用于保障银行系统中的数据安全传输与存储。该加密机支持磁条卡与IC卡两种类型的应用场景,并提供了一套完整的密钥管理和加密/解密功能。本文将...
CPU卡,也称为智能卡,是一种内置微型处理器的卡片,广泛应用于金融、交通、医疗等领域。其核心是Card Operating System(COS),它是CPU卡的灵魂,管理着卡片上的所有资源和应用程序。本篇文章将深入探讨CPU卡系统...
在IT领域,尤其是在金融行业的支付系统中,MAC(Message Authentication Code)是一种广泛使用的安全机制,用于验证数据的完整性和来源的合法性。8583报文是金融交易中使用的一种标准格式,通常用于电子资金转账(EFT...
在金融行业中,银联8583报文是一种广泛用于银行卡交易处理的通信协议标准,其主要用于电子支付系统中的数据交换。PIN(Personal Identification Number)码是银行卡用户的身份验证密码,确保只有持卡人才能进行交易...
SJJ1309-A金融数据密码机是一款专门设计用于金融行业的加密设备,支持国密算法,适用于银行及金融机构的数据加密需求。本手册主要介绍了该密码机的编程接口、命令集以及相关的安全策略。 #### 二、重要概念与功能 ...
《中国金融集成电路(IC)卡规范》是指导中国金融行业IC卡应用的重要技术文件之一,旨在确保金融交易的安全性和可靠性。其中,第7部分——《借记/贷记应用安全规范》重点阐述了在借记卡和信用卡交易过程中如何通过一...
三重DES因其更高的安全性,在很多领域得到了广泛应用,尤其是在金融行业、网络安全等领域。例如,在银行卡支付系统中,3DES用于保证交易的安全性;在安全套接层(SSL/TLS)协议中,3DES被用来保护互联网上的敏感数据...
- **金融领域**:银行交易数据的加密保护。 - **电信行业**:通信数据的安全传输。 - **政府机构**:敏感信息的加密存储和传输。 #### 六、AES的合规性和限制 AES加密算法的实现和应用受到联邦加密模块出口控制的...
《JRT 0094.3-2012 中国金融移动支付近场支付应用第3部分:报文结构及要素》是中国金融行业移动支付标准系列的一部分,主要规定了近场支付场景下的报文结构及其组成要素。该标准旨在为金融行业的移动支付系统提供...
### pboc 2.0-20080924-07-借记贷记应用安全规范 #### 概述 《中国金融集成电路(IC)卡规范第7部分...这不仅有助于保护用户的资金安全,也为金融机构提供了一套完整的技术指导方案,促进了整个金融行业的健康发展。
《智能卡行业技术详解——基于XHWriteCard的PCSC读卡器应用》 智能卡行业,作为信息安全和数据加密的重要领域,一直以来都是信息技术的重要组成部分。在这个领域中,XHWriteCard是一个实用的小工具,它专门用于PCSC...
尽管如此,ANSI X9系列标准在金融行业的历史地位不容忽视,它们奠定了现代网络安全和密码学的基础。如今,这些标准已被更新和扩展,以适应不断变化的安全威胁和法规要求,如FIPS 140-2和EMV等。 总结来说,ANSI X...