1
lhbc 2015-08-29 16:02:54 +08:00
这样的话, SLA 就变成了 SLA1*SLA2 ,风险大很多
直接 AES256 加密传上去不更好? 我就把 vhd 用 Bitlocker 加密传 Dropbox 上 |
2
noli OP @lhbc SLA 这个是可以优化的,例如适度的冗余,那么这个 SLA 还可以提高。
对称加密上传保存当然简单又直接,但问题是,密钥保存?如果保存密钥的节点出了问题,譬如你的手机,或者你自己的电脑。 如果利用一致性哈希之类的东西,那么连密钥本身都可以拆成不同的片段来保存,这样安全性还是可以得到保障的。 |
3
openroc 2015-08-29 16:20:22 +08:00
@noli 这个想法,我之前做了一些研究,技术上可行性问题不大,关在在于,大多数用户,不关系数据安全性,只有少数关心,如 1 楼。:)
|
4
noli OP @openroc
我想忽悠你一起做这件事。你有研究的话,那我刚好有工程能力,似乎王八对绿豆哦。 XD 并且我相信,国内不关心安全性,可是国外关心啊,愿意为隐私和存储付钱的人不在少数。 反正数据存储是刚需,潜力很大。 是可以一试的,我们可以只提供技术部署方案,譬如提供 SDK 啊,提供服务器软件啊什么的,不直接提供存储。 |
5
openroc 2015-08-29 16:33:19 +08:00
|
7
zhuang 2015-08-29 16:53:34 +08:00 via iPad
如果文件本身没有加密,分块之后一样会由 entropy 泄露信息。如果加密了,单一 csp 也没有破解能力。
分块可以提供 (m,n ) 冗余,即只要总共 n 份分块的 m 份即可恢复。这可能是唯一优点。 你并不能提供密码学意义上更好的安全性,同时降低了易用性。 |
8
lhbc 2015-08-29 17:02:45 +08:00
|
9
MuhammadWang 2015-08-29 17:11:27 +08:00
看下这个,基于 blockchain
http://storj.io/ |
10
noli OP @zhuang 你说的很对,在没有提供新的密码学算法的前提下,确实并不能提供密码学意义上更高的安全性。对比现有的解决方法来说,并不是类似 ECC 对比 RSA 这样的提供更多 option 的增加了社会福利。
但是这个东西的好处其实就是针对存在多个 CSP 的实际情况来说的。 设想这样的一个情景,现在同时有两家 CSP 可以为我提供服务,我要存储一些加密了的数据,那我要怎么存储才能保证安全性? 最常见的想法就像 1 楼说的,数据加密存在一个或两个 CSP 那里,然后加密密钥由另外一个 CSP 存储。注意,这个 CSP 可能只是你的手机或者你的电脑。 这样一定是存在单点故障导致整个系统失效的可能性的。 但是,真正的分布式存储,或者说去中心化的存储就是为了消除这种情况而产生的技术。 如果我把两个 CSP 提供的存储, format 成同某个 RAID level 为基础的 fs ,单个 csp 只是一个 block device , 然后把数据分发和冗余 放在这个 fs 上, 那么从 单个 CSP 的角度来看,信息的熵其实是更少的,因为无法观察到例如 file metadata 这样的信息。更不要说组合起来还原出原始信息了。 又因为,从工程上来说,两个 CSP 同时 compromise 的概率是远小于 一个 CSP compromise 的概率的。所以是以这种方式来提高安全性的。 |
11
zhuang 2015-08-29 17:34:57 +08:00
@noli
> 数据加密存在一个或两个 CSP 那里,然后加密密钥由另外一个 CSP 存储。 > 这样一定是存在单点故障导致整个系统失效的可能性的。 你混淆了“安全”的定义,从安全( Security )的角度上说,最终只取决于密码学算法和密钥管理,而多点存储关注的是可靠性( Reliablity )问题。虽然中文都叫做“数据安全”,但完全是两码事情。 我强调的是,分块之后你还要不要加密? - 不加密,毫无安全性( Security )可言 - 加密,安全性( Security )等同密码学方案 如果你想解决与“隐私”相关的问题,你找错了方向。 另外你对于 entropy 的理解不对,能不能观察到 metadata 并不是决定熵多少的因素。(事实情况是,如果你能观察到 metadata 了,相对于加密的情况来说,前者的熵更低而后者的熵更高。) http://yurichev.com/blog/entropy/ 这里有非常详细的解释, entropy 分析价值比一般认知当中大得多。 |
12
itfanr 2015-08-29 17:44:45 +08:00 via Android
你的想法有点意思啊
|
13
noli OP @zhuang 说实话,我的理论研究水平并不高,应该看不懂给你给我的那个连接的内容。
但我没有理解错你说的 securtiy 的意思,我上面说的单点故障,说的就是单点在密码学上的安全性无法保证,导致系统安全性被破坏的意思。 下面我提出针对你的 “ security ” 的疑问给出的回答,或许你可以进一步提示我漏洞在哪里?或者提出一个具体的方法?因为我没办法针对一个“理论”而不是一个“算法”提出自己的回应。 @lhbc 我先归纳一下我怎么理解你(们)的意思。你的想法其实是从最终存储步骤来反推整个安全体系的,对吗? 你的意思是说,譬如某 A 君想要在我所提出的这个分布式文件系统中存储一些东西,尤其是我需要存储一个对所有文件加解密有重要影响的密钥(不管是私钥还是对称解密的密钥不影响这个问题的讨论)的时候,这个安全性会失效,因为: 一,如果我要把这个密钥以 *不*加*密* 的方式,切分成 n 份分别存放在不同的 CSP 之上。那么存在的风险就是: 1 )这 n 个 CSP 都妥协了,被攻破了,并且联合起来还原出数据……不予讨论,因为这样的情况下完全没有安全可言,什么措施都白搭。 2 )有一个强大的中间人,或者有一个冒充者分别从这 n 个 CSP 中, 以 CSP 以为合法的方式拿到了这个密钥的数据。简单来说就是,中间人可以完全截获信道中通过的信息。这样什么安全也是白搭的 但是,总的来说,即使是以不加密的方式,总体的安全性仍然是有保障的,起码等同于 n 个 CSP 同时被攻克,或者 n 条通信信道同时泄密 的概率。因为这个数据安全性肯定高于 一个 CSP 的安全性。 我们已经知道,不加密存储的安全几乎等价于所有的 CSP 都 compromise 的可能性,那么进一步, 二,如果我要把这个密钥以加密的方式来存储。那么问题来了,怎么保存加密这个 “密钥的密钥” ?是不是正如 @zhuang 在 11 楼所说的那样,“安全性” 等同于加密所用的密码学方案? 其实这是一个想当然而产生的伪问题,想当然的地方在于: 1 )我们真保存“一个”密钥吗?不是的,既然选择了多个 CSP ,我们可以让存储在不同 CSP 上的由同一份数据分拆而来的不同部分,分别使用不同的密钥;然后把某个 CSP 上使用的密钥拆开放在其他不同的 CSP 上来存储。当这些数据,同时汇聚在一起的时候(例如在客户端上),才可以使用解密算法揭开。 这样虽在形式上等同于不加密地存储了密钥,但从工程实现上的难度上来说,除非所有的 CSP 都被攻破,否则任意一份数据被泄漏的可能性,大约等于没有密码的情况下攻破解密的难度。 不过这样依然防止不了超强中间人攻击。为此,我们还需要完成第二重保障。 2 )与同一台机器上的 app 和 fs 之间的关系不一样,分布式文件存储的客户端和服务端并不在同一台机器上,因此使用公钥系统是可能的。有了公钥系统,我们就可以以 token 的方式来管理可访问数据的客户端。那么中间人即使截获了全部的数据,数据的安全性还是可以有保障的。 当然这部分我还没想好怎么融合在分布式存储里面。 :目 |
14
zhuang 2015-08-29 20:39:24 +08:00
@noli
“所有的 CSP 不会同时被攻破”只能保证“数据分块不会同时被第三方获取”,但并不能保证“被获取的单一分块不会泄漏数据”。 所以结论就是,你的分布式设想,依旧要做文件级的加密才行。不加密我就可以说它不安全。 解决“隐私”问题的是加密算法,而不是你的“分布式”方案。如果你做产品这么宣传,那是另外一回事。 ========== 一个系统的安全性,是由最健壮的环节决定还是由最薄弱的环节决定?理论上是最健壮的环节,而实际上是最薄弱的环节。 你的设想里有分布式模块和文件级加密模块,那么会存在两种可能: - 分布式模块安全性更高 - 文件级加密模块安全性更高 前一种情况,你要关心文件级加密算法别被破解了(小概率);后一种情况,你给一个安全系统增加了薄弱的一环,暴露了更大的攻击面。 从实际应用来看,多数应用都要依赖加密算法作为最后一道屏障,考虑到代码实现,几乎没有任何产品可以比纯加密算法能提供更高的安全性。 ========== 你还是动手做一下吧,等你做过就知道哪里有问题了。 |
15
ProfFan 2015-08-29 20:53:38 +08:00
bittorrent sync?
|
16
noli OP @zhuang 当然,作为产品级别的存储,不加一个加密好像也对不起“产品级”这个词 ^-^。
于是,只要按照上面所说提到的,不同数据块以不同密钥加密,那么只要不是加密密钥完全泄漏(例如只获取到了加密密钥的一部分),那么“被获取的单一分块不会泄漏数据” 应该是成立的吧,因为加密密钥被分布在了所有的 CSP 上,要么全部泄漏——在只获取一部分的密钥数据无法推算出密钥其他部分的前提下,而这个前提对于多数对称加密的算法来说是成立的——要么完全等效于没有泄漏。 又所以,这种通过分布式保存密钥的方式,来解决了传统云存储密钥保存和数据的、因为保存单点故障导致系统整体安全性失效的 做法,难道不可以简单归纳为,分布式的方案来解决隐私问题吗? ---- 实际情况中,多数需要担心的就是分布式模块中的弱点部分被攻破,成为集中突破的缺口。 考虑到整个分布式存储中所有的节点扮演的功能都是一样的,可以大致上看作每个节点的攻破难度是相当的。那么最大的弱点应该就是在于客户端上了。 当然,使用类似于 CRUSH 之类的算法,来保证单点存储和访问量均衡,那是实现中肯定要解决的问题。 |
17
lhbc 2015-08-29 21:09:56 +08:00
@noli
无论你怎么折腾,在密码学算法一样的情况下,安全性是完全一样的。 我们应当把网卡之外的数据视作完全不安全。 当你把数据传输出去的时候,无论你存哪里,分割几份,用了多少躲猫猫技术,都应该视作“可以被人获取”,而且事实上 CSP 确实是可以获取到你的数据。 那最终的安全性就要靠密码学算法来保障。 分两份密钥或者多少份,最终在解密的时候,所有密钥还是集中在一起,这和一份密钥没有什么区别。 至于密钥管理,目前的 USB Key 比你想的分 n 份 要安全得多。 |
18
noli OP @lhbc 哈哈,密钥集中在一起的时候(例如在客户端上)怎么解决安全问题,那就不是这个东西要解决的问题啦。这里归根到底是要解决,如果陈老师把艳照上传到这里,那么艳照会不会从这里泄漏。
而且,以你的方式来说的话,任何密码学以外保证数据安全的努力都是无用功了。 可是,这个理解方式不符合现实啊,例如你的数据存在阿里云上跟存在 GCE 上的安全性,肯定就不一样。 |
19
lhbc 2015-08-29 21:56:18 +08:00
@noli
呵呵 陈老师要是用 TrueCrypt 或者 Mac 自带的 AES 加密,结果跟你这样搞的效果是一样的,除非他的私钥保管不严而且被人逼着说出口令。 我的逻辑是建立在你要把数据传输到公网的情况下。 如果只是私下保存,那当然还有其他提高安全等级的方法。 阿里云和 GCE 确实没什么区别,反正你都不可控。 |
20
noli OP @lhbc 如果以上说的这些你看完了依然觉得和 truecrypt 单机保存是一样的,那么很遗憾我的表达能力不足以让你理解差别在哪里
阿里云和 GCE 不一样的地方在于一个细节。这么说吧,即使你可以以足够快的速度从 GCE 的机房在运行时拆下一个硬盘,那么你在这个硬盘上读取到任意一个用户的数据,跟他传送到网络上的数据,即以用户密钥解密前的数据,都是完全不一样的,但对阿里云来说,则不是。 |
21
Blockchain 2015-08-30 06:05:14 +08:00
其实目前所有基于 blockchain 的分布式技术,都可以用来预防单点失败的情况。
那当然就可以用来存储一些比较重要的文件和信息了。 问题的关键是:去中心化的效率不如中心化的好,所以安全和效率有时候真的是要用户自己来取舍。 |
22
mengzhuo 2015-08-30 07:46:41 +08:00 via iPhone
我就是做分布式存储的
涉密不上网 楼主你想太多了 |
23
noli OP |
24
JamesRuan 2015-08-30 14:51:23 +08:00
说了这么多,就没有人提到 Threshold Cryptography 吗?
|
25
noli OP @JamesRuan Threshold Cryptography 有意思。
之前我没听说过这个词,但是貌似把密钥切开几份,合并时才能用的做法,就是这个? |
26
JamesRuan 2015-08-30 22:02:06 +08:00
|
27
openroc 2015-08-30 22:05:01 +08:00
mac 下做个加密分片的开源应用。对某些个人用户还是有价值的。至少以前看过的一些相关文章,网盘是个人隐私数据或一些公司机密数据泄露的一个途径。:)
|
28
itfanr 2015-09-02 14:52:54 +08:00
@MuhammadWang Storj is based on blockchain technology and peer-to-peer protocols to provide the most secure, private, and encrypted cloud storage.
|
29
noli OP |
31
macrohard 2016-05-15 11:59:54 +08:00
storj
|