• 关于

    对称密钥加密可以做什么

    的搜索结果

回答

HTTPS基本原理 一、http为什么不安全。 http协议没有任何的加密以及身份验证的机制,非常容易遭遇窃听、劫持、篡改,因此会造成个人隐私泄露,恶意的流量劫持等严重的安全问题。 国外很多网站都支持了全站https,国内方面目前百度已经在年初完成了搜索的全站https,其他大型的网站也在跟进中,百度最先完成全站https的最大原因就是百度作为国内最大的流量入口,劫持也必然是首当其冲的,造成的有形的和无形的损失也就越大。关于流量劫持问题,我在另一篇文章中也有提到,基本上是互联网企业的共同难题,https也是目前公认的比较好的解决方法。但是https也会带来很多性能以及访问速度上的牺牲,很多互联网公司在做大的时候都会遇到这个问题:https成本高,速度又慢,规模小的时候在涉及到登录和交易用上就够了,做大以后遇到信息泄露和劫持,想整体换,代价又很高。 2、https如何保证安全 要解决上面的问题,就要引入加密以及身份验证的机制。 这时我们引入了非对称加密的概念,我们知道非对称加密如果是公钥加密的数据私钥才能解密,所以我只要把公钥发给你,你就可以用这个公钥来加密未来我们进行数据交换的秘钥,发给我时,即使中间的人截取了信息,也无法解密,因为私钥在我这里,只有我才能解密,我拿到你的信息后用私钥解密后拿到加密数据用的对称秘钥,通过这个对称密钥来进行后续的数据加密。除此之外,非对称加密可以很好的管理秘钥,保证每次数据加密的对称密钥都是不相同的。 但是这样似乎还不够,如果中间人在收到我的给你公钥后并没有发给你,而是自己伪造了一个公钥发给你,这是你把对称密钥用这个公钥加密发回经过中间人,他可以用私钥解密并拿到对称密钥,此时他在把此对称密钥用我的公钥加密发回给我,这样中间人就拿到了对称密钥,可以解密传输的数据了。为了解决此问题,我们引入了数字证书的概念。我首先生成公私钥,将公钥提供给相关机构(CA),CA将公钥放入数字证书并将数字证书颁布给我,此时我就不是简单的把公钥给你,而是给你一个数字证书,数字证书中加入了一些数字签名的机制,保证了数字证书一定是我给你的。 所以综合以上三点: 非对称加密算法(公钥和私钥)交换秘钥 + 数字证书验证身份(验证公钥是否是伪造的) + 利用秘钥对称加密算法加密数据 = 安全 3、https协议简介 为什么是协议简介呢。因为https涉及的东西实在太多了,尤其是一些加密算法,非常的复杂,对于这些算法面的东西就不去深入研究了,这部分仅仅是梳理一下一些关于https最基本的原理,为后面分解https的连接建立以及https优化等内容打下理论基础。 3.1 对称加密算法 对称加密是指加密和解密使用相同密钥的加密算法。它要求发送方和接收方在安全通信之前,商定一个密钥。对称算法的安全性依赖于密钥,泄漏密钥就意味着任何人都可以对他们发送或接收的消息解密,所以密钥的保密性对通信至关重要。 对称加密又分为两种模式:流加密和分组加密。 流加密是将消息作为位流对待,并且使用数学函数分别作用在每一个位上,使用流加密时,每加密一次,相同的明文位会转换成不同的密文位。流加密使用了密钥流生成器,它生成的位流与明文位进行异或,从而生成密文。现在常用的就是RC4,不过RC4已经不再安全,微软也建议网络尽量不要使用RC4流加密。 分组加密是将消息划分为若干位分组,这些分组随后会通过数学函数进行处理,每次一个分组。假设需要加密发生给对端的消息,并且使用的是64位的分组密码,此时如果消息长度为640位,就会被划分成10个64位的分组,每个分组都用一系列数学公式公式进行处理,最后得到10个加密文本分组。然后,将这条密文消息发送给对端。对端必须拥有相同的分组密码,以相反的顺序对10个密文分组使用前面的算法解密,最终得到明文的消息。比较常用的分组加密算法有DES、3DES、AES。其中DES是比较老的加密算法,现在已经被证明不安全。而3DES是一个过渡的加密算法,相当于在DES基础上进行三重运算来提高安全性,但其本质上还是和DES算法一致。而AES是DES算法的替代算法,是现在最安全的对称加密算法之一。分组加密算法除了算法本身外还存在很多种不同的运算方式,比如ECB、CBC、CFB、OFB、CTR等,这些不同的模式可能只针对特定功能的环境中有效,所以要了解各种不同的模式以及每种模式的用途。这个部分后面的文章中会详细讲。 对称加密算法的优、缺点: 优点:算法公开、计算量小、加密速度快、加密效率高。 缺点:(1)交易双方都使用同样钥匙,安全性得不到保证; (2)每对用户每次使用对称加密算法时,都需要使用其他人不知道的惟一钥匙,这会使得发收信双方所拥有的钥匙数量呈几何级数增长,密钥管理成为用户的负担。 (3)能提供机密性,但是不能提供验证和不可否认性。 3.2 非对称加密算法 在非对称密钥交换算法出现以前,对称加密一个很大的问题就是不知道如何安全生成和保管密钥。非对称密钥交换过程主要就是为了解决这个问题,使得对称密钥的生成和使用更加安全。 密钥交换算法本身非常复杂,密钥交换过程涉及到随机数生成,模指数运算,空白补齐,加密,签名等操作。 常见的密钥交换算法有RSA,ECDHE,DH,DHE等算法。涉及到比较复杂的数学问题,下面就简单介绍下最经典的RSA算法。RSA:算法实现简单,诞生于1977年,历史悠久,经过了长时间的破解测试,安全性高。缺点就是需要比较大的素数也就是质数(目前常用的是2048位)来保证安全强度,很消耗CPU运算资源。RSA是目前唯一一个既能用于密钥交换又能用于证书签名的算法。我觉得RSA可以算是最经典的非对称加密算法了,虽然算法本身都是数学的东西,但是作为最经典的算法,我自己也花了点时间对算法进行了研究,后面会详细介绍。 非对称加密相比对称加密更加安全,但也存在两个明显缺点: 1,CPU计算资源消耗非常大。一次完全TLS握手,密钥交换时的非对称解密计算量占整个握手过程的90%以上。而对称加密的计算量只相当于非对称加密的0.1%,如果应用层数据也使用非对称加解密,性能开销太大,无法承受。 2,非对称加密算法对加密内容的长度有限制,不能超过公钥长度。比如现在常用的公钥长度是2048位,意味着待加密内容不能超过256个字节。 所以公钥加密(极端消耗CPU资源)目前只能用来作密钥交换或者内容签名,不适合用来做应用层传输内容的加解密。 3.3 身份认证 https协议中身份认证的部分是由数字证书来完成的,证书由公钥、证书主体、数字签名等内容组成,在客户端发起SSL请求后,服务端会将数字证书发给客户端,客户端会对证书进行验证(验证查看这张证书是否是伪造的。也就是公钥是否是伪造的),并获取用于秘钥交换的非对称密钥(获取公钥)。 数字证书有两个作用: 1,身份授权。确保浏览器访问的网站是经过CA验证的可信任的网站。 2,分发公钥。每个数字证书都包含了注册者生成的公钥(验证确保是合法的,非伪造的公钥)。在SSL握手时会通过certificate消息传输给客户端。 申请一个受信任的数字证书通常有如下流程: 1,终端实体(可以是一个终端硬件或者网站)生成公私钥和证书请求。 2,RA(证书注册及审核机构)检查实体的合法性。如果个人或者小网站,这一步不是必须的。 3,CA(证书签发机构)签发证书,发送给申请者。 4,证书更新到repository(负责数字证书及CRL内容存储和分发),终端后续从repository更新证书,查询证书状态等。 数字证书验证: 申请者拿到CA的证书并部署在网站服务器端,那浏览器发起握手接收到证书后,如何确认这个证书就是CA签发的呢。怎样避免第三方伪造这个证书。答案就是数字签名(digital signature)。数字签名是证书的防伪标签,目前使用最广泛的SHA-RSA(SHA用于哈希算法,RSA用于非对称加密算法)数字签名的制作和验证过程如下: 1,数字签名的签发。首先是使用哈希函数对待签名内容进行安全哈希,生成消息摘要,然后使用CA自己的私钥对消息摘要进行加密。 2,数字签名的校验。使用CA的公钥解密签名,然后使用相同的签名函数对待签名证书内容进行签名并和服务端数字签名里的签名内容进行比较,如果相同就认为校验成功。 需要注意的是: 1)数字签名签发和校验使用的密钥对是CA自己的公私密钥,跟证书申请者提交的公钥没有关系。 2)数字签名的签发过程跟公钥加密的过程刚好相反,即是用私钥加密,公钥解密。 3)现在大的CA都会有证书链,证书链的好处一是安全,保持根CA的私钥离线使用。第二个好处是方便部署和撤销,即如果证书出现问题,只需要撤销相应级别的证书,根证书依然安全。 4)根CA证书都是自签名,即用自己的公钥和私钥完成了签名的制作和验证。而证书链上的证书签名都是使用上一级证书的密钥对完成签名和验证的。 5)怎样获取根CA和多级CA的密钥对。它们是否可信。当然可信,因为这些厂商跟浏览器和操作系统都有合作,它们的公钥都默认装到了浏览器或者操作系统环境里。 3.4 数据完整性验证 数据传输过程中的完整性使用MAC算法来保证。为了避免网络中传输的数据被非法篡改,SSL利用基于MD5或SHA的MAC算法来保证消息的完整性。 MAC算法是在密钥参与下的数据摘要算法,能将密钥和任意长度的数据转换为固定长度的数据。发送者在密钥的参与下,利用MAC算法计算出消息的MAC值,并将其加在消息之后发送给接收者。接收者利用同样的密钥和MAC算法计算出消息的MAC值,并与接收到的MAC值比较。如果二者相同,则报文没有改变;否则,报文在传输过程中被修改,接收者将丢弃该报文。 由于MD5在实际应用中存在冲突的可能性比较大,所以尽量别采用MD5来验证内容一致性。SHA也不能使用SHA0和SHA1,中国山东大学的王小云教授在2005年就宣布破解了 SHA-1完整版算法。微软和google都已经宣布16年及17年之后不再支持sha1签名证书。MAC算法涉及到很多复杂的数学问题,这里就不多讲细节了。 专题二--【实际抓包分析】 抓包结果: fiddler: wireshark: 可以看到,百度和我们公司一样,也采用以下策略: (1)对于高版本浏览器,如果支持 https,且加解密算法在TLS1.0 以上的,都将所有 http请求重定向到 https请求 (2)对于https请求,则不变。 【以下只解读https请求】 1、TCP三次握手 可以看到,我们访问的是 http://www.baidu.com/ , 在初次建立 三次握手的时候, 用户是去 连接 8080端口的(因为公司办公网做了代理,因此,我们实际和代理机做的三次握手,公司代理机再帮我们去连接百度服务器的80端口) 2、CONNECT 建立 由于公司办公网访问非腾讯域名,会做代理,因此,在进行https访问的时候,我们的电脑需要和公司代理机做 " CONNECT " 连接(关于 " CONNECT " 连接, 可以理解为虽然后续的https请求都是公司代理机和百度服务器进行公私钥连接和对称秘钥通信,但是,有了 " CONNECT " 连接之后,可以认为我们也在直接和百度服务器进行公私钥连接和对称秘钥通信。 ) fiddler抓包结果: CONNECT之后, 后面所有的通信过程,可以看做是我们的机器和百度服务器在直接通信 3、 client hello 整个 Secure Socket Layer只包含了: TLS1.2 Record Layer内容 (1)随机数 在客户端问候中,有四个字节以Unix时间格式记录了客户端的协调世界时间(UTC)。协调世界时间是从1970年1月1日开始到当前时刻所经历的秒数。在这个例子中,0x2516b84b就是协调世界时间。在他后面有28字节的随机数( random_C ),在后面的过程中我们会用到这个随机数。 (2)SID(Session ID) 如果出于某种原因,对话中断,就需要重新握手。为了避免重新握手而造成的访问效率低下,这时候引入了session ID的概念, session ID的思想很简单,就是每一次对话都有一个编号(session ID)。如果对话中断,下次重连的时候,只要客户端给出这个编号,且服务器有这个编号的记录,双方就可以重新使用已有的"对话密钥",而不必重新生成一把。 因为我们抓包的时候,是几个小时内第一次访问 https://www.baodu.com 首页,因此,这里并没有 Session ID. (稍会儿我们会看到隔了半分钟,第二次抓包就有这个Session ID) session ID是目前所有浏览器都支持的方法,但是它的缺点在于session ID往往只保留在一台服务器上。所以,如果客户端的请求发到另一台服务器,就无法恢复对话。session ticket就是为了解决这个问题而诞生的,目前只有Firefox和Chrome浏览器支持。 (3) 密文族(Cipher Suites): RFC2246中建议了很多中组合,一般写法是"密钥交换算法-对称加密算法-哈希算法,以“TLS_RSA_WITH_AES_256_CBC_SHA”为例: (a) TLS为协议,RSA为密钥交换的算法; (b) AES_256_CBC是对称加密算法(其中256是密钥长度,CBC是分组方式); (c) SHA是哈希的算法。 浏览器支持的加密算法一般会比较多,而服务端会根据自身的业务情况选择比较适合的加密组合发给客户端。(比如综合安全性以及速度、性能等因素) (4) Server_name扩展:( 一般浏览器也支持 SNI(Server Name Indication)) 当我们去访问一个站点时,一定是先通过DNS解析出站点对应的ip地址,通过ip地址来访问站点,由于很多时候一个ip地址是给很多的站点公用,因此如果没有server_name这个字段,server是无法给与客户端相应的数字证书的,Server_name扩展则允许服务器对浏览器的请求授予相对应的证书。 还有一个很好的功能: SNI(Server Name Indication)。这个的功能比较好,为了解决一个服务器使用多个域名和证书的SSL/TLS扩展。一句话简述它的工作原理就是,在连接到服务器建立SSL连接之前先发送要访问站点的域名(Hostname),这样服务器根据这个域名返回一个合适的CA证书。目前,大多数操作系统和浏览器都已经很好地支持SNI扩展,OpenSSL 0.9.8已经内置这一功能,据说新版的nginx也支持SNI。) 4、 服务器回复(包括 Server Hello, Certificate, Certificate Status) 服务器在收到client hello后,会回复三个数据包,下面分别看一下: 1)Server Hello 1、我们得到了服务器的以Unix时间格式记录的UTC和28字节的随机数 (random_S)。 2、Seesion ID,服务端对于session ID一般会有三种选择 (稍会儿我们会看到隔了半分钟,第二次抓包就有这个Session ID) : 1)恢复的session ID:我们之前在client hello里面已经提到,如果client hello里面的session ID在服务端有缓存,服务端会尝试恢复这个session; 2)新的session ID:这里又分两种情况,第一种是client hello里面的session ID是空值,此时服务端会给客户端一个新的session ID,第二种是client hello里面的session ID此服务器并没有找到对应的缓存,此时也会回一个新的session ID给客户端; 3)NULL:服务端不希望此session被恢复,因此session ID为空。 3、我们记得在client hello里面,客户端给出了21种加密族,而在我们所提供的21个加密族中,服务端挑选了“TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256”。 (a) TLS为协议,RSA为密钥交换的算法; (b) AES_256_CBC是对称加密算法(其中256是密钥长度,CBC是分组方式); (c) SHA是哈希的算法。 这就意味着服务端会使用ECDHE-RSA算法进行密钥交换,通过AES_128_GCM对称加密算法来加密数据,利用SHA256哈希算法来确保数据完整性。这是百度综合了安全、性能、访问速度等多方面后选取的加密组合。 2)Certificate 在前面的https原理研究中,我们知道为了安全的将公钥发给客户端,服务端会把公钥放入数字证书中并发给客户端(数字证书可以自签发,但是一般为了保证安全会有一个专门的CA机构签发),所以这个报文就是数字证书,4097 bytes就是证书的长度。 我们打开这个证书,可以看到证书的具体信息,这个具体信息通过抓包报文的方式不是太直观,可以在浏览器上直接看。 (点击 chrome 浏览器 左上方的 绿色 锁型按钮) 3)Server Hello Done 我们抓的包是将 Server Hello Done 和 server key exchage 合并的包: 4)客户端验证证书真伪性 客户端验证证书的合法性,如果验证通过才会进行后续通信,否则根据错误情况不同做出提示和操作,合法性验证包括如下: 证书链的可信性trusted certificate path,方法如前文所述; 证书是否吊销revocation,有两类方式离线CRL与在线OCSP,不同的客户端行为会不同; 有效期expiry date,证书是否在有效时间范围; 域名domain,核查证书域名是否与当前的访问域名匹配,匹配规则后续分析; 5)秘钥交换 这个过程非常复杂,大概总结一下: (1)首先,其利用非对称加密实现身份认证和密钥协商,利用非对称加密,协商好加解密数据的 对称秘钥(外加CA认证,防止中间人窃取 对称秘钥) (2)然后,对称加密算法采用协商的密钥对数据加密,客户端和服务器利用 对称秘钥 进行通信; (3)最后,基于散列函数验证信息的完整性,确保通信数据不会被中间人恶意篡改。 此时客户端已经获取全部的计算协商密钥需要的信息:两个明文随机数random_C和random_S与自己计算产生的Pre-master(由客户端和服务器的 pubkey生成的一串随机数),计算得到协商对称密钥; enc_key=Fuc(random_C, random_S, Pre-Master) 6)生成 session ticket 如果出于某种原因,对话中断,就需要重新握手。为了避免重新握手而造成的访问效率低下,这时候引入了session ID的概念, session ID的思想很简单,就是每一次对话都有一个编号(session ID)。如果对话中断,下次重连的时候,只要客户端给出这个编号,且服务器有这个编号的记录,双方就可以重新使用已有的"对话密钥",而不必重新生成一把。 因为我们抓包的时候,是几个小时内第一次访问 https://www.baodu.com 首页,因此,这里并没有 Session ID. (稍会儿我们会看到隔了半分钟,第二次抓包就有这个Session ID) session ID是目前所有浏览器都支持的方法,但是它的缺点在于session ID往往只保留在一台服务器上。所以,如果客户端的请求发到另一台服务器,就无法恢复对话。session ticket就是为了解决这个问题而诞生的,目前只有Firefox和Chrome浏览器支持。 后续建立新的https会话,就可以利用 session ID 或者 session Tickets , 对称秘钥可以再次使用,从而免去了 https 公私钥交换、CA认证等等过程,极大地缩短 https 会话连接时间。 7) 利用对称秘钥传输数据 【半分钟后,再次访问百度】: 有这些大的不同: 由于服务器和浏览器缓存了 Session ID 和 Session Tickets,不需要再进行 公钥证书传递,CA认证,生成 对称秘钥等过程,直接利用半分钟前的 对称秘钥 加解密数据进行会话。 1)Client Hello 2)Server Hello
玄学酱 2019-12-02 01:27:08 0 浏览量 回答数 0

回答

看代码了。不要太高估码农的智商了。比如如果是PHP开源软件,基本都是MD5揉来揉去,如果是.NET开源软件,基本都是DES揉来揉去。 99%的加密就是base64,md5,rc4,des3等揉来揉去,其中90%的加密是MD5散列做的,就是加一点切一点。 ######回复 @blu10ph : 你说的没错。但是,绝大部分开源软件的作者水平没这么高,尤其是业务软件,就是我说的拿几个最简单最常见的揉来揉去,加点盐,掐头去尾什么的。你以为他们懂什么椭圆双曲线加密,什么SHA3最新一代散列?######加密还分可逆和不可逆,对称不对称######老大果然是老大,”揉“用得非常之精妙。###### md5 ###### 你没有把明文贴出来,谁能猜得到? ######根据你的要求,提供了4对明文密文,呵呵######一定不是MD5###### 你这个密文长度都不固定,怎么确定呀。反正肯定不是MD5,好像也不是DES。或者有两种加密算法。因为第四段密文长度和其他不一样。 ######长度问题,你可能想复杂了######呵呵,楼主就少换了个行,你们就以为有一行长度不一致?看上去离MD5不远,至少最后一步是MD5的16位加密。######那一行长的 确实就是那么长啊###### md5 ######呵呵,说的对哦 我补充了几组明文密文组 能帮我看看算法吗?######回复 @婕仪伟琪 : 这个网站确实能通过密文反查到MD5等加密数据。我用过几次。你可以去看看.www.cmd5.com。并且从这个网站你可以看到,光摘要算法,就有十几二十种,更不用说对称,非对称算法了。而且,比如对称算法,只要明文不同,即使密钥相同,算出来的密文也完全不同。加密解密有三要素(明文,密钥,算法),才能算出密文,你只给出一串无意义的密文,神仙也推不出算法或者明文来。######MD5###### ######所以你不给出一条明文或密钥,根本不能判断是什么算法加密出来的。######在原问题上补充了4对明文密文,呵呵
kun坤 2020-06-03 14:04:23 0 浏览量 回答数 0

回答

先说一些基础的东东吧,加密和解密是为了信息在传递过程中被他人知晓,对明文所做的混淆,看你举的这个场景,我感觉你对加密这一套的理解还有些欠缺。再多在网上学习一下吧。不过大体上也可以回答你的两个问题。 Q:比如一个系统我要加密用户密码,是不是我整个系统只需要一对公匙私匙?还是每个密码要一对 A: 不管是对称加密算法如AES的密钥(一个)还是非对称加密算法RSA的密钥(一对), 当然只需要一个(一对),要多个也没有意义,因为一个(一对)已经安全了哈。 Q: 然后数据库是保持加密得到的byte二进制数组吗还是保存什么,时应该前台页面用公匙把密码加密吗? A: 当然是保存密文,反正看起来是乱码,当然你理解成BYTE数组也行。因为你选的是RSA一对密钥,所以你任选一个来加密,另一个解密就行了。 ######非常感谢######保存密码请用单向散列函数,不要用任何可逆算法,即使被爆库也拿不到明文。RSA主要的作用是防止消息被篡改,具体应用可以百度,存密码侧重的是防止明文暴露。######这个场景只是举例,主要是后面那几个问题啊。求大神指点指点######你的应用场景用散列就行,没必要可逆。 ######这个场景只是举例,主要是后面那几个问题啊。求大神指点######系统用户的加密是用的是MD5加密,然后存入数据库,用户登录的时候就将用户输入的密码MD5加密然后和数据库的数据比对,如果相同就登录成功######像 散列(HASH)这种映射算法,仅仅是为了不明文保存数据而已,是不可逆的,不能从密文(映射值)中还原出明文。所以它也不应该归为加密算法一类。 ######密码用 md5 处理是绝对错误的,应该用 bcrypt 或者 scrypt ######绝对。即使加 salt 的 md5 也是极度不可靠的。 建议使用 bcrypt,用得很广。scrypt 更强,但相关的密码学分析还不多。######这么绝对么。。 你说那两种我都没接触过。
kun坤 2020-06-03 11:21:02 0 浏览量 回答数 0

回答

token是用于跨域和跨连接/会话的一种权限认证方式。 而你本地破解泄露是属于本地漏洞。 这是两码事。 混在一块考虑没有意义。 ###### 我觉得没有办法   最多复杂化求解  想了几种方式  均告失败 1  对token进行对称加密   密钥发送给服务器   使用时  请求服务器获取密钥  解密    漏洞   盗窃者也可以请求服务器获取密钥  解密 2   client端和server端共同维护一个字符表  client端得到的token在表中的序列值  使用时  根据序列值还原token     漏洞   盗窃者可以破解该表 ###### 3    token定期失效   要求用户重新登入       漏洞   token有效期内问题依然存在   同时会导致用户体验不佳 ###### 引用来自“张山疯”的评论 token是用于跨域和跨连接/会话的一种权限认证方式。 而你本地破解泄露是属于本地漏洞。 这是两码事。 混在一块考虑没有意义。 谢谢科普  不过我的问题你没有回答 我是问  在移动应用领域  如何有效的保护用户数据  说token只是一个引子  希望大家能更好的理解  谢谢 ###### 1. token 与本地IP,或者user agent做关联,具体可以取如手机硬件参数等,这样可以防止拿token到其它地方用的问题,但还是不能解决全部,因为理论上来说,客户端所有东西都可以伪造成和原来的一模一样 2. 就是对于一些敏感操作,如转帐,改密等,需要进行密码或者令牌的二次确认 ######不要明文发,在本地通过一定的规则加密后再发。######拿到ROOT权限 就不安全了 问题里提到的手机淘宝案例 你可以看看######  我也有这样的困惑。 有什么好的建议么? 上HTTPS 也不是一个绝对保险的办法###### 引用来自“shijacky”的评论 token 与本地IP,或者user agent做关联,具体可以取如手机硬件参数等,这样可以防止拿token到其它地方用的问题,但还是不能解决全部,因为理论上来说,客户端所有东西都可以伪造成和原来的一模一样就是对于一些敏感操作,如转帐,改密等,需要进行密码或者令牌的二次确认 1   漏洞   盗窃都也可以获取本地IP  use agent等相关数据   再通过分析apk代码  解密 2   这是一个好方法   不过此处只讨论没有第三方输入的情况 ###### 昨晚灵泉涌现   想到一个解决方案   早上来不及洗刷   电脑一查  果然OK 4   client端获取token后   通过native代码获取app签名文件内容   此处指android  app打包时的签名文件  ios wp8请自行对照  结合token+签名内容+S  使用公钥加密后发送给server端验证  OK     漏洞  无 签名文件内容必须在app运行之后才可以得到  分析apk原文件无法得到    注   S为随机数  server端维护 ######回复 @欣儿 : 是的 所以下面我评论了 本来我以为这个内容第三方获取不到 既然能获取就没有意义了 这个方案里的内容 必须要满足私有 值固定 系统级 才可行######这个,还是可以破解吧,安卓的可以获取运行时数据,就是说,只要运行,签名这些也可以得到######果然是我高兴的太早 经过验证 第三方同样可以通过native代码获取签名内容 所以这个方案存在漏洞######我记得是:签名是可以通过apk 的pakageInfo获取到的。如果查询所有的安装包的签名信息,找出包名一样的签名信息。会不会就破解了呢?######你说的签名文件内容是什么?sha1?######家门钥匙丢了,自己却不知道,此时如何防盗?######你这个比喻不恰当 client和server的通信 是联机操作 不是单机操作 单机操作当然没有安全可言
kun坤 2020-06-05 14:25:22 0 浏览量 回答数 0

回答

介绍了Amazon S3 使用的认证: http://dodomail.iteye.com/blog/1744389 ######这个很简单啊,把所有参数都做一次加密就是,秘钥你来生成授权给你的下游就是了,后台再做记录ip的的功能,这样谁请求你的API了就都知道了,自己实现也很快的######tokening,或者id这些加密,获取后再解密,密钥自己生成。就是加个验证的key值就可以吧,每次提交数据验证key的正确性###### 做一个认证服务,提供一个认证的webapi,用户先访问它获取token,然后拿着token去访问所有的webapi。每次接收到请求就拿着token找认证服务寻求验证。验证通过则papapa,不然就404。 你要说的是这种么?还是对访问做验证限制? ######回复 @devilsitan : 也是啊,那你再看看刚刚问的第二个问题######@liujiduo tomcat只是个web服务器。。不明白为什么和它要有关呢。。webapi又不是在tomcat上跑的。######回复 @devilsitan : 还有就是这种给webapi加token认证的方式,应该是我事先给某些指定的APP(比如我的iOS客户端或安卓客户端)发放私钥,然后它们根据私钥获取token。那如果我的网站前端通过ajax访问这些api是不是也需要通过token认证呢?如果是的话那不就会暴露出私钥了吗?先谢谢啦^_^######回复 @devilsitan : 那另一种 基于HTTP Digest认证的方式也是只用代码实现,不需要修改tomcat的配置吗?######@liujiduo 那这种和服务器就没多大关系了啥。。只要你有webapi服务在就行,什么访问都是通过HTTP来请求的。接口也很简单一个认证,一个验证。认证服务内部看你怎么设计,要么是简单的用户-权限,要么是用户-角色-权限,要么是带约束的用户-角色-权限,还有更加灵活的二者皆有,采取优先拒绝。###### 引用来自“devilsitan”的评论 做一个认证服务,提供一个认证的webapi,用户先访问它获取token,然后拿着token去访问所有的webapi。每次接收到请求就拿着token找认证服务寻求验证。验证通过则papapa,不然就404。 你要说的是这种么?还是对访问做验证限制? 肯定是要带Token的,访问还是用户名密码,认证通过cookie里存的就是用户名和token,token是有有效期的,过了有效期你就需要重新分配一个token。这个暴露问题,我也不知道肿么办,不过人家要存心搞你,这些还有用么。你看Digest还不是私钥放在cookie里,虽然用算法加密一次和服务器比对,人家只需要截下你的包,把加密后的验证字符拿去验证就是了。我没看出什么区别######回复 @liujiduo : 可以参考上面的那位给的亚马逊s3的rest api认证。也可以看下openstack的keystone的验证模式。都是一个令牌,就看你怎么用和。简单的就是我前面说的那样,复杂的更安全的就是他们那样。######明白了,谢谢!###### 顶 ######ajax的时候检测客户端用户权限不可以吗?###### Http Digest认证也就是防止重放攻击,如果是局域网项目感觉对认证的要求不用太高,主要还是网络安全和访问的监控和预警,要是互联网的觉得还是非对称签名比较安全,存粹算法决定。###### 引用来自“HandMU”的评论ajax的时候检测客户端用户权限不可以吗? 用户权限是跟用户绑定的,而客户端访问接口可能没有用户的概念,这样就不合适了啊######回复 @HandMU : 你没明白他意思,webapi,可能是非本系统用户######可参考open auth######回复 @liujiduo : 都会有基于用户权限检测的。你钻到死角了。######回复 @HandMU : 是啊,难道对于webapi的安全认证就没有一个好的办法么?不知道淘宝这些网站是怎么做的######ajax理论上还是post、get,依然带上所有你能使用的用户信息。###### 引用来自“刘敬伟”的评论 Http Digest认证也就是防止重放攻击,如果是局域网项目感觉对认证的要求不用太高,主要还是网络安全和访问的监控和预警,要是互联网的觉得还是非对称签名比较安全,存粹算法决定。 不是局域网项目,我是想让某些数据敏感的接口只能被已授权的客户端访问,而不是让别人只要知道了url就能恶意请求和操纵我的接口,我查了Http Basic和Http Digest的认证流程,但就是不清楚怎么应用到项目中来。######我觉得你的思路有点混乱,没搞清楚到底认证什么,怎么认证,认证力度如何。这些都要根据你的网络环境、服务器系统、还有你处理的数据类型有关系。如果不想用第三方安全策略,我建议采用非对称的安全算法,针对用户信息最签名和验证。在这个基础上对你接口接收的用户请求进行监控,如果有必要的话你接收的数据要进行过滤,就像支付宝也不是实时到账,中间肯定有一个审核数据的再次分发的缓冲处理机制。
kun坤 2020-06-02 15:55:28 0 浏览量 回答数 0

回答

" 介绍了Amazon S3 使用的认证: http://dodomail.iteye.com/blog/1744389 ######这个很简单啊,把所有参数都做一次加密就是,秘钥你来生成授权给你的下游就是了,后台再做记录ip的的功能,这样谁请求你的API了就都知道了,自己实现也很快的######tokening,或者id这些加密,获取后再解密,密钥自己生成。就是加个验证的key值就可以吧,每次提交数据验证key的正确性###### 做一个认证服务,提供一个认证的webapi,用户先访问它获取token,然后拿着token去访问所有的webapi。每次接收到请求就拿着token找认证服务寻求验证。验证通过则papapa,不然就404。 你要说的是这种么?还是对访问做验证限制? ######回复 @devilsitan : 也是啊,那你再看看刚刚问的第二个问题###### @liujiduo tomcat只是个web服务器。。不明白为什么和它要有关呢。。webapi又不是在tomcat上跑的。######回复 @devilsitan : 还有就是这种给webapi加token认证的方式,应该是我事先给某些指定的APP(比如我的iOS客户端或安卓客户端)发放私钥,然后它们根据私钥获取token。那如果我的网站前端通过ajax访问这些api是不是也需要通过token认证呢?如果是的话那不就会暴露出私钥了吗?先谢谢啦^_^######回复 @devilsitan : 那另一种 基于HTTP Digest认证的方式也是只用代码实现,不需要修改tomcat的配置吗?###### @liujiduo 那这种和服务器就没多大关系了啥。。只要你有webapi服务在就行,什么访问都是通过HTTP来请求的。接口也很简单一个认证,一个验证。认证服务内部看你怎么设计,要么是简单的用户-权限,要么是用户-角色-权限,要么是带约束的用户-角色-权限,还有更加灵活的二者皆有,采取优先拒绝。###### 引用来自“devilsitan”的评论 做一个认证服务,提供一个认证的webapi,用户先访问它获取token,然后拿着token去访问所有的webapi。每次接收到请求就拿着token找认证服务寻求验证。验证通过则papapa,不然就404。 你要说的是这种么?还是对访问做验证限制? 肯定是要带Token的,访问还是用户名密码,认证通过cookie里存的就是用户名和token,token是有有效期的,过了有效期你就需要重新分配一个token。这个暴露问题,我也不知道肿么办,不过人家要存心搞你,这些还有用么。你看Digest还不是私钥放在cookie里,虽然用算法加密一次和服务器比对,人家只需要截下你的包,把加密后的验证字符拿去验证就是了。我没看出什么区别######回复 @liujiduo : 可以参考上面的那位给的亚马逊s3的rest api认证。也可以看下openstack的keystone的验证模式。都是一个令牌,就看你怎么用和。简单的就是我前面说的那样,复杂的更安全的就是他们那样。######明白了,谢谢!###### 顶 ######ajax的时候检测客户端用户权限不可以吗?###### Http Digest认证也就是防止重放攻击,如果是局域网项目感觉对认证的要求不用太高,主要还是网络安全和访问的监控和预警,要是互联网的觉得还是非对称签名比较安全,存粹算法决定。###### 引用来自“HandMU”的评论ajax的时候检测客户端用户权限不可以吗? 用户权限是跟用户绑定的,而客户端访问接口可能没有用户的概念,这样就不合适了啊######回复 @HandMU : 你没明白他意思,webapi,可能是非本系统用户######可参考open auth######回复 @liujiduo : 都会有基于用户权限检测的。你钻到死角了。######回复 @HandMU : 是啊,难道对于webapi的安全认证就没有一个好的办法么?不知道淘宝这些网站是怎么做的######ajax理论上还是post、get,依然带上所有你能使用的用户信息。###### 引用来自“刘敬伟”的评论 Http Digest认证也就是防止重放攻击,如果是局域网项目感觉对认证的要求不用太高,主要还是网络安全和访问的监控和预警,要是互联网的觉得还是非对称签名比较安全,存粹算法决定。 不是局域网项目,我是想让某些数据敏感的接口只能被已授权的客户端访问,而不是让别人只要知道了url就能恶意请求和操纵我的接口,我查了Http Basic和Http Digest的认证流程,但就是不清楚怎么应用到项目中来。######我觉得你的思路有点混乱,没搞清楚到底认证什么,怎么认证,认证力度如何。这些都要根据你的网络环境、服务器系统、还有你处理的数据类型有关系。如果不想用第三方安全策略,我建议采用非对称的安全算法,针对用户信息最签名和验证。在这个基础上对你接口接收的用户请求进行监控,如果有必要的话你接收的数据要进行过滤,就像支付宝也不是实时到账,中间肯定有一个审核数据的再次分发的缓冲处理机制。"
montos 2020-06-03 22:34:05 0 浏览量 回答数 0

回答

Spring Cloud 学习笔记(一)——入门、特征、配置 0 放在前面 0.1 参考文档 http://cloud.spring.io/spring-cloud-static/Brixton.SR7/ https://springcloud.cc/ http://projects.spring.io/spring-cloud/ 0.2 maven配置 org.springframework.boot spring-boot-starter-parent 1.5.2.RELEASE org.springframework.cloud spring-cloud-dependencies Dalston.RELEASE pom import org.springframework.cloud spring-cloud-starter-config org.springframework.cloud spring-cloud-starter-eureka 0.3 简介 Spring Cloud为开发人员提供了快速构建分布式系统中的一些通用模式(例如配置管理,服务发现,断路器,智能路由,微代理,控制总线,一次性令牌,全局锁,领导选举,分布式 会话,群集状态)。 分布式系统的协调引出样板模式(boiler plate patterns),并且使用Spring Cloud开发人员可以快速地实现这些模式来启动服务和应用程序。 它们可以在任何分布式环境中正常工作,包括开发人员自己的笔记本电脑,裸机数据中心和受管平台,如Cloud Foundry。 Version: Brixton.SR7 1 特征 Spring Cloud专注于为经典用例和扩展机制提供良好的开箱即用 分布式/版本配置 服务注册与发现 路由选择 服务调用 负载均衡 熔断机制 全局锁 领导人选举和集群状态 分布式消息 2 原生云应用程序 原生云是应用程序开发的一种风格,鼓励在持续交付和价值驱动领域的最佳实践。 Spring Cloud的很多特性是基于Spring Boot的。更多的是由两个库实现:Spring Cloud Context and Spring Cloud Commons。 2.1 Spring Cloud Context: 应用上下文服务 Spring Boot关于使用Spring构建应用有硬性规定:通用的配置文件在固定的位置,通用管理终端,监控任务。建立在这个基础上,Spring Cloud增加了一些额外的特性。 2.1.1 引导应用程序上下文 Spring Cloud会创建一个“bootstrap”的上下文,这是主应用程序的父上下文。对应的配置文件拥有最高优先级,并且,默认不能被本地配置文件覆盖。对应的文件名bootstrap.yml或bootstrap.properties。 可通过设置spring.cloud.bootstrap.enabled=false来禁止bootstrap进程。 2.1.2 应用上下文层级结构 当用SpringApplication或SpringApplicationBuilder创建应用程序上下文时,bootstrap上下文将作为父上下文被添加进去,子上下文将继承父上下文的属性。 子上下文的配置信息可覆盖父上下文的配置信息。 2.1.3 修改Bootstrap配置文件位置 spring.cloud.bootstrap.name(默认是bootstrap),或者spring.cloud.bootstrap.location(默认是空) 2.1.4 覆盖远程配置文件的值 spring.cloud.config.allowOverride=true spring.cloud.config.overrideNone=true spring.cloud.config.overrideSystemProperties=false 2.1.5 定制Bootstrap配置 在/META-INF/spring.factories的key为org.springframework.cloud.bootstrap.BootstrapConfiguration,定义了Bootstrap启动的组件。 在主应用程序启动之前,一开始Bootstrap上下文创建在spring.factories文件中的组件,然后是@Beans类型的bean。 2.1.6 定制Bootstrap属性来源 关键点:spring.factories、PropertySourceLocator 2.1.7 环境改变 应用程序可通过EnvironmentChangedEvent监听应用程序并做出响应。 2.1.8 Refresh Scope Spring的bean被@RefreshScope将做特殊处理,可用于刷新bean的配置信息。 注意 需要添加依赖“org.springframework.boot.spring-boot-starter-actuator” 目前我只在@Controller测试成功 需要自己发送POST请求/refresh 修改配置文件即可 2.1.9 加密和解密 Spring Cloud可对配置文件的值进行加密。 如果有"Illegal key size"异常,那么需要安装JCE。 2.1.10 服务点 除了Spring Boot提供的服务点,Spring Cloud也提供了一些服务点用于管理,注意都是POST请求 /env:更新Environment、重新绑定@ConfigurationProperties跟日志级别 /refresh重新加载配置文件,刷新标记@RefreshScope的bean /restart重启应用,默认不可用 生命周期方法:/pause、/resume 2.2 Spring Cloud Commons:通用抽象 服务发现、负载均衡、熔断机制这种模式为Spring Cloud客户端提供了一个通用的抽象层。 2.2.1 RestTemplate作为负载均衡客户端 通过@Bean跟@LoadBalanced指定RestTemplate。注意URI需要使用虚拟域名(如服务名,不能用域名)。 如下: @Configuration public class MyConfiguration { @LoadBalanced @Bean RestTemplate restTemplate() { return new RestTemplate(); } } public class MyClass { @Autowired private RestTemplate restTemplate; public String doOtherStuff() { String results = restTemplate.getForObject(" http://stores/stores", String.class); return results; } } 2.2.2 多个RestTemplate对象 注意@Primary注解的使用。 @Configuration public class MyConfiguration { @LoadBalanced @Bean RestTemplate loadBalanced() { return new RestTemplate(); } @Primary @Bean RestTemplate restTemplate() { return new RestTemplate(); } } public class MyClass { @Autowired private RestTemplate restTemplate; @Autowired @LoadBalanced private RestTemplate loadBalanced; public String doOtherStuff() { return loadBalanced.getForObject(" http://stores/stores", String.class); } public String doStuff() { return restTemplate.getForObject(" http://example.com", String.class); } } 2.2.3 忽略网络接口 忽略确定名字的服务发现注册,支持正则表达式配置。 3 Spring Cloud Config Spring Cloud Config提供服务端和客户端在分布式系统中扩展配置。支持不同环境的配置(开发、测试、生产)。使用Git做默认配置后端,可支持配置环境打版本标签。 3.1 快速开始 可通过IDE运行或maven运行。 默认加载property资源的策略是克隆一个git仓库(at spring.cloud.config.server.git.uri')。 HTTP服务资源的构成: /{application}/{profile}[/{label}] /{application}-{profile}.yml /{label}/{application}-{profile}.yml /{application}-{profile}.properties /{label}/{application}-{profile}.properties application是SpringApplication的spring.config.name,(一般来说'application'是一个常规的Spring Boot应用),profile是一个active的profile(或者逗号分隔的属性列表),label是一个可选的git标签(默认为"master")。 3.1.1 客户端示例 创建以Spring Boot应用即可,添加依赖“org.springframework.cloud:spring-cloud-starter-config”。 配置application.properties,注意URL为配置服务端的地址 spring.cloud.config.uri: http://myconfigserver.com 3.2 Spring Cloud Config 服务端 针对系统外的配置项(如name-value对或相同功能的YAML内容),该服务器提供了基于资源的HTTP接口。使用@EnableConfigServer注解,该服务器可以很容易的被嵌入到Spring Boot 系统中。使用该注解之后该应用系统就是一个配置服务器。 @SpringBootApplication @EnableConfigServer public class ConfigApplicion { public static void main(String[] args) throws Exception { SpringApplication.run(ConfigApplicion.class, args); } } 3.2.1 资源库环境 {application} 对应客户端的"spring.application.name"属性 {profile} 对应客户端的 "spring.profiles.active"属性(逗号分隔的列表) {label} 对应服务端属性,这个属性能标示一组配置文件的版本 如果配置库是基于文件的,服务器将从application.yml和foo.yml中创建一个Environment对象。高优先级的配置优先转成Environment对象中的PropertySource。 3.2.1.1 Git后端 默认的EnvironmentRepository是用Git后端进行实现的,Git后端对于管理升级和物理环境是很方便的,对审计配置变更也很方便。也可以file:前缀从本地配置库中读取数据。 这个配置库的实现通过映射HTTP资源的{label}参数作为git label(提交id,分支名称或tag)。如果git分支或tag的名称包含一个斜杠 ("/"),此时HTTP URL中的label需要使用特殊字符串"(_)"来替代(为了避免与其他URL路径相互混淆)。如果使用了命令行客户端如 curl,请谨慎处理URL中的括号(例如:在shell下请使用引号''来转义它们)。 Git URI占位符 Spring Cloud Config Server支持git库URL中包含针对{application}和 {profile}的占位符(如果你需要,{label}也可包含占位符, 不过要牢记的是任何情况下label只指git的label)。所以,你可以很容易的支持“一个应用系统一个配置库”策略或“一个profile一个配置库”策略。 模式匹配和多资源库 spring: cloud: config: server: git: uri: https://github.com/spring-cloud-samples/config-repo repos: simple: https://github.com/simple/config-repo special: pattern: special*/dev*,special/dev* uri: https://github.com/special/config-repo local: pattern: local* uri: file:/home/configsvc/config-repo 如果 {application}/{profile}不能匹配任何表达式,那么将使用“spring.cloud.config.server.git.uri”对应的值。在上例子中,对于 "simple" 配置库, 匹配模式是simple/* (也就说,无论profile是什么,它只匹配application名称为“simple”的应用系统)。“local”库匹配所有application名称以“local”开头任何应用系统,不管profiles是什么(来实现覆盖因没有配置对profile的匹配规则,“/”后缀会被自动的增加到任何的匹配表达式中)。 Git搜索路径中的占位符 spring.cloud.config.server.git.searchPaths 3.2.1.2 版本控制后端文件系统使用 伴随着版本控制系统作为后端(git、svn),文件都会被check out或clone 到本地文件系统中。默认这些文件会被放置到以config-repo-为前缀的系统临时目录中。在Linux上,譬如应该是/tmp/config-repo- 目录。有些操作系统routinely clean out放到临时目录中,这会导致不可预知的问题出现。为了避免这个问题,通过设置spring.cloud.config.server.git.basedir或spring.cloud.config.server.svn.basedir参数值为非系统临时目录。 3.2.1.3 文件系统后端 使用本地加载配置文件。 需要配置:spring.cloud.config.server.native.searchLocations跟spring.profiles.active=native。 路径配置格式:classpath:/, classpath:/config,file:./, file:./config。 3.2.1.4 共享配置给所有应用 基于文件的资源库 在基于文件的资源库中(i.e. git, svn and native),这样的文件名application 命名的资源在所有的客户端都是共享的(如 application.properties, application.yml, application-*.properties,etc.)。 属性覆盖 “spring.cloud.config.server.overrides”添加一个Map类型的name-value对来实现覆盖。 例如 spring: cloud: config: server: overrides: foo: bar 会使所有的配置客户端应用程序读取foo=bar到他们自己配置参数中。 3.2.2 健康指示器 通过这个指示器能够检查已经配置的EnvironmentRepository是否正常运行。 通过设置spring.cloud.config.server.health.enabled=false参数来禁用健康指示器。 3.2.3 安全 你可以自由选择任何你觉得合理的方式来保护你的Config Server(从物理网络安全到OAuth2 令牌),同时使用Spring Security和Spring Boot 能使你做更多其他有用的事情。 为了使用默认的Spring Boot HTTP Basic 安全,只需要把Spring Security 增加到classpath中(如org.springframework.boot.spring-boot-starter-security)。默认的用户名是“user”,对应的会生成一个随机密码,这种情况在实际使用中并没有意义,一般建议配置一个密码(通过 security.user.password属性进行配置)并对这个密码进行加密。 3.2.4 加密与解密 如果远程属性包含加密内容(以{cipher}开头),这些值将在通过HTTP传递到客户端之前被解密。 使用略 3.2.5 密钥管理 配置服务可以使用对称(共享)密钥或者非对称密钥(RSA密钥对)。 使用略 3.2.6 创建一个测试密钥库 3.2.7 使用多密钥和循环密钥 3.2.8 加密属性服务 3.3 可替换格式服务 配置文件可加后缀".yml"、".yaml"、".properties" 3.4 文本解释服务 /{name}/{profile}/{label}/{path} 3.5 嵌入配置服务器 一般配置服务运行在单独的应用里面,只要使用注解@EnableConfigServer即可嵌入到其他应用。 3.6 推送通知和总线 添加依赖spring-cloud-config-monitor,激活Spring Cloud 总线,/monitor端点即可用。 当webhook激活,针对应用程序可能已经变化了的,配置服务端将发送一个RefreshRemoteApplicationEvent。 3.7 客户端配置 3.7.1 配置第一次引导 通过spring.cloud.config.uri属性配置Config Server地址 3.7.2 发现第一次引导 如果用的是Netflix,则用eureka.client.serviceUrl.defaultZone进行配置。 3.7.3 配置客户端快速失败 在一些例子里面,可能希望在没有连接配置服务端时直接启动失败。可通过spring.cloud.config.failFast=true进行配置。 3.7.4 配置客户端重试 添加依赖spring-retry、spring-boot-starter-aop,设置spring.cloud.config.failFast=true。默认的是6次重试,初始补偿间隔是1000ms,后续补偿为1.1指数乘数,可通过spring.cloud.config.retry.*配置进行修改。 3.7.5 定位远程配置资源 路径:/{name}/{profile}/{label} "name" = ${spring.application.name} "profile" = ${spring.profiles.active} (actually Environment.getActiveProfiles()) "label" = "master" label对于回滚到之前的版本很有用。 3.7.6 安全 通过spring.cloud.config.password、spring.cloud.config.username进行配置。 答案来源于网络
养狐狸的猫 2019-12-02 02:18:34 0 浏览量 回答数 0

回答

区块链(blockchian)技术是随比特币等数字加密货币兴起的一种新型分布式数据组织方法及运算方式,通过去中心化来集体维护一个可靠数据库的技术。该技术将一段时间内的两两配对数据(比特币中指交易)打包成数据块(block),然后利用具有激励性质的共识算法让点对点对等网(p2p网络)中的所有节点产生的数据块保持一致,并生成数据指纹验证其有效性然后链接(chain)下一个数据块。在这个过程中,所有节点的地位都是对等的,没有所谓的服务器和客户端之分,因此被称为去中心化的方式,这很好地解决了数据在存储和共享环节中存在的安全和信任问题。通过区块链技术,在数据共享过程中可明确数据的来源、所有权和使用权,达到数据在存储上不可篡改、在流通上路径可追溯、在数据管理上可审计的目的,保证数据在存储、共享、审计等环节中的安全,实现真正意义上的数据全流程管理,进一步拓展数据的流通渠道、促进数据的共享共用、激发数据的价值挖掘、增强数据在流通中的信任。同时,基于区块链的分布式共享“总账”这一特点,在平台安全方面,可达到有效消除单点故障、抵御网络攻击的目的。这些特点使得区块链技术特别适合应用于具有保密要求的大数据运算领域。 近年来,国外已有一些研究机构和企业将区块链应用在电子证件认证和身份认证领域(见图1-1)。2015年7月,区块链初创公司ShoCard获150万美元投资,将实体身份证件的数据指纹保存在区块链上。用户用手机扫描自己的身份证件,ShoCard应用会把证件信息加密后保存在用户本地,把数据指纹保存到区块链。区块链上的数据指纹受一个私钥控制,只有持有私钥的用户自己才有权修改,ShoCard本身无权修改。同时,为了防范用户盗用他人身份证件扫描上传,ShoCard还允许银行等机构对用户的身份进行背书,确保真实性。2015年9月,去中心化的管理项目比特国(Bitnation)在区块链上实施“电子公民”(e-Residents)计划。用户在其官网上通过区块链登记成为Bitnation的“公民”,并获得Bitnation“世界公民身份证”。2015年12月,Bitnation与爱沙尼亚政府签署协议,将为“电子公民”项目提供公证服务,无论他们身居何处,在何处做生意,都可以在区块链上享受结婚证明、出生证明、商务合同和其他服务。区块链是一个公共账本,全世界数以千万计的计算机都存储着其副本,具备公开公证的可复制性与不可更改性,比目前各国使用的传统公证方法更安全。2016年6月,美国国安局向区块链初创公司Factom拨款19.9万美元用于物联网设备数字身份安全性开发,利用区块链技术来验证物联网设备,阻止因设备欺骗而导致的非授权访问,以此来确保数据完整性;美国区块链公司Certchain为文档建立数据指纹,提供去中心化的文件所有权证明;OneName公司则提供了另一种身份服务,即任何比特币的用户都可以把自己的比特币地址和自己的姓名、Twitter、Facebook等账号绑定起来,相当于为每个社交账户提供了一个公开的比特币地址和进行数字签名的能力。 在国内,有一些研究机构也在开展区块链在电子政务方面的应用研究。闵旭蓉等人[6]设计了一种电子证照共享平台,利用区块链技术的去中心化、不可篡改、分布式共同记账、非对称加密和数据安全存储等特点,实现电子证照的安全可信共享,实现各地、各部门和各层级间政务数据的互联互通,支撑政府高效施政。黄步添等人[7]明确了电子证照参与者的权利和义务,基于联盟链思想和轮值机制,设计区块链平台的系统架构、数据结构和业务流程,提供电子证照的颁发、存储、更新、验证等功能,实现多中心、协同式电子证照管理,从而为电子证照拥有者以及相关应用系统提供便捷的电子证照服务。蒋海等人[8]提供了一种区块链身份构建及验证方法,有效缓解了因个别认证机构的问题影响用户身份信息准确性的情况,然而其原始数据来源为第三方认证机构,未能解决数据的真实性问题,且其只进行身份验证,未与其他证件锚定,扩展性不强,发挥的作用有限。 此外,有一些教育和科研机构将区块链技术应用于教育证书领域。2015 年,麻省理工学院的媒体实验室(The MIT MediaLab)应用区块链技术研发了学习证书平台,并发布了一个类似“比特币钱包”的手机App[9]。学习者可以利用该App存储和分享自己的学习证书,随身携带、随时展示,且拥有重申成绩的权力。学习者不能擅自更改学习证书的内容,但能自主决定将什么证书展示给哪个访问者。在查询时,将数字证书的密钥点对点地发送给用人单位或学生等有关需求方,确保证书不会被恶意查询。无独有偶,位于旧金山的软件培训机构—Holberton School从2017年开始利用区块链技术记录学历,并在区块链上共享学生的学历证书信息。同样,学分也可以通过这项技术认证和交换。对于学生来说,这一应用拓宽了他们获得教育评价的途径,方便了学习记录和学历信息的保存。从更长远的眼光来看,利用区块链记录跨地区、跨院校甚至跨国学习者的信息,可以使在不同环境中学习的学习者获得同样有效的学习记录。区块链技术在教育证书方面可能的应用方式包括:为在线教育提供有公信力和低成本的证书系统;作为智能合约,完成教育契约和存证;作为分布式的学习记录存储,记录学习轨迹,共享学习学分。从应用规模和范围来看,区块链在教育领域的应用范围可以小到单个教育机构、学校联盟,大到全国甚至全球性的教育互认互通联盟。
问问小秘 2019-12-02 03:10:04 0 浏览量 回答数 0
阿里云企业服务平台 陈四清的老板信息查询 上海奇点人才服务相关的云产品 爱迪商标注册信息 安徽华轩堂药业的公司信息查询 小程序定制 上海微企信息技术相关的云产品 国内短信套餐包 ECS云服务器安全配置相关的云产品 天籁阁商标注册信息 开发者问答 阿里云建站 自然场景识别相关的云产品 万网 小程序开发制作 视频内容分析 视频集锦 代理记账服务 北京芙蓉天下的公司信息查询