如何实现/使用安全的“一次读取”本地文件访问系统?

发布于 2024-08-04 12:32:50 字数 1761 浏览 5 评论 0原文

有人知道安全的“一次读取”本地文件访问系统吗?或者如何创建一个?我意识到,如果数据要在系统上使用,那么它必须能够被读取,但我认为可能会严格限制数据的可用方式,并减少数据在其他地方复制和使用的可能性。

这些是我的要求:

我想在 USB 记忆棒上存储一个“安全/加密”数据文件(可以是只读 CD/DVD,但如果读/写 USB 甚至软盘更好),并且该文件能够一旦输入密码,就会在逐块解码的基础上被读取一次(主要是仅一次)。文件内容可能是基本文本/xml(或文本编码数据),并且主要作为顺序流读取。数据(理想情况下)可以通过普通的 Windows 文件访问方法读取,即:std 文件、FSO 对象(流和文本文件)、所有 BASIC PC (VB6/VB.NET) 文件处理方法,甚至 Excel 文本(导入)。是的,我知道这可能会破坏该对象(因为这样的文件可以打开/保存),但我仍然希望这种可能性。最后,一旦满足“访问”标准,该设备将阻止进一步的访问。

只能在本地 PC 系统上访问数据。没有 LAN,不支持设备共享。设备上的数据不应通过正常方式复制。如果可能的话,将使用正常方法将数据写入设备,如果需要,则使用特殊应用程序。

为了简单起见,只要一个密码、一个文件、一种用途和一个用户就很好了,但其他可能的增强功能包括:(锦上添花)...

  • 允许“n”打开
  • 具有多个密码的 2 个或更多用户,单独使用
  • 筒仓密码,让另外 2 个用户一起签名以获得访问权限(甚至 至少有 m 个用户中的 n 个用户一起签名才能访问)
  • 第一个块访问时应给出密码提示,独立于 调用第一个块的应用程序
  • 可以嵌入密码/自动
  • 将访问权限绑定到指定的机器/mac/ip/磁盘序列号(或 其他机器代码)
  • 将访问权限绑定到指定程序/应用程序
  • (如果可能),删除并安全地覆盖数据文件

我对此的第一个猜测表明它需要一个“伪设备”驱动程序,该驱动程序将显示为(或替换)标准可移动设备驱动程序。驱动程序将逐个扇区处理每个文件块,如果未经授权,则拒绝提供进一步解码的块。设备不应提供正常的目录列表,但可以向用户提供某种形式的内容摘要(可选)。

与 DRM 系统不同,我不需要任何形式的在线访问/身份验证(但会考虑),我更喜欢独立的系统。

我花了很长时间努力寻找这样的设备/系统,但还没有找到。大多数设备和系统工具(例如:Iomega/ironkey)似乎可以解锁对文件的访问,但没有限制,即:一旦解锁,可读取多次。

性能不是问题。软盘读取速度慢就可以了。加密方法是不可知的,任何相当强大的 40 位+(128 位)都可以。我无法告诉你数据是什么或它的用途是什么,我只需要一种方法将数据提供给某人并尽可能限制其使用以及他们可以用它做什么。这是保护机密数据的真正要求,而不是针对 DRM 或 MP3/视频或类似内容。

我是一名“办公室”开发人员,不太熟悉设备驱动程序或 DRM - 现在我应该从哪里开始这样的项目?已经有什么东西可供公众使用了吗?

谢谢 - 蒂姆。

PS:更新

我应该指出,我只是希望在我们自己和单个特定指定服务提供商之间传递数据。我不希望他们复制我们提供的数据。它将被使用一次来支持“单一”一次性过程,然后就完成了。由于数据是“流式传输/读取”的,因此应该“使用”数据。如果处理失败,我们将重新向服务提供商发出数据。数据仍然是我们的财产,不会被出售/许可。

我确实意识到没有任何解决方案是万无一失的,但风险/回报比应该阻止随意破坏系统的尝试。这些数据没有明确的商业价值。

PPS:这是一个真正的要求......你会怎么做?

从 @eriksons 深思熟虑的答案上的点赞来看,你们说“不可能/不要打扰”——但除了亲自监督数据按照我们的意愿使用之外,你们会做什么?

does anybody know of a secure 'read-once' local file access system? Or how one might create one? I realise that if data is to be used on a system, then it must be capable of being read, but I think it may be possible to severely limit how data is made available and reduce the possibility of it being copied and used elsewhere.

These are my requirements:

I want to store a 'secure/encrypted' data-file on a USB stick (could be read-only CD/DVD, but better if read/write USB or even a floppy) and have this file capable of being read once (and mainly only once), on a decoded block-by-block basis, once a password has been entered. The file content is probably basic text/xml (or text-encoded data) and is to be read mainly as a sequential stream. The data (ideally) can be read by normal windows file-access methods, ie: a std file, FSO objects (stream and text file), all BASIC PC (VB6/VB.NET) file handling methods, even Excel text (import). yes, I know this probably defeats the object (as such a file can then be opened/saved), but I would still want this possibility. Finally, once the 'access' criteria had been met, the device would prevent further access.

Access to the data would be on a local PC system only. No LAN, no device sharing supported. Data on the device should not be copyable by normal means. Data would be written to the device using normal methods if possible or a special application if necessary.

To keep things simple, just one password, one file, one use, and one user would be great, but other possible enhancements include: (as icing on the cake)...

  • allowing 'n' opens
  • having multiple passwords 2 or more users, acting individually
  • silo-passwords, having 2 more users sign together to get access (or even
    having at least n from m more users sign together to get access)
  • Password prompt should be given on first block-access, independent of
    application calling the first block
  • Password could be embedded/automatic
  • tie the access to a nominated machine/mac/ip/disk serial number (or
    other machine-code)
  • tie the access to a nominated program /application
  • if possible, delete and securely overwrite the data file

My first guess at doing this suggests that it would need a 'psuedo-device' driver that would appear as an extention to (or replacement of) the std removable-device driver. The driver would handle each file block, sector by sector, and refuse to server further decoded blocks if not authorised. The device should not give normal directory listings, but some some form of content summary may be given to a user (optional).

Unlike a DRM system, I don't want any form of on-line acces/authentication (but would consider it), I would prefer a self-contained system.

I have looked long and hard for a such a device/system, and haven't found one yet. Most devices and system tools (eg: Iomega/ironkey) appear to unlock access to files, but without limit, ie: read-many, once unlocked.

Performance is not an issue. Slow floppy read-rate would be okay. Encyption method is agnostic, anything reasonably strong 40bit+ (128bit) would be fine. I can't tell you what the data is or whats its for, I just need a way to give data to somebody and limit its use as far as possible and what they can do with it. Its a real requirement to protect confidential data and not meant for DRM or MP3s/Videos or similar.

I am an 'office' developer and not really familiar with device-drivers or DRM - Now where would I start with such a project? Is there anything out-there available to joe-public already?

Thanks - Tim.

PS: Update

I should point out that I just wish to pass data between ourselves and a single specific nominated service-provider. I don't want them to copy the data we provide. It will be used once to support a 'singular' one-off process and then be done-with. As the data is 'streamed/read' it should be 'consumed'. if the process fails, we will re-issue the data to the service-provider. the data remains our property, it is not being sold/licensed.

I do realise that no solution will be foolproof, but the risk/reward ratio should dissuade casual attempts to break the system. The data has no explicit commercial value.

PPS: Its a real requirement... What would you do?

Judging by the upvotes on @eriksons thoughtful answer, you guys are saying 'not possible / don't bother' - but apart from personally supervising that the data is used according to our wishes, what would you do?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

漆黑的白昼 2024-08-11 12:32:50

执行摘要:这不是一个现实的解决方案。重新思考这个过程,这样就不需要“读一次”了。

上世纪 90 年代末,一些公司(我想到的是 Disappearing Inc.,他们至少有一个竞争对手)试图在通用硬件上制作“自毁式”电子邮件。他们花费了数百万.com 美元来开发实际上不起作用的系统。

我知道的唯一潜在的解决方案是使用 受信任的平台模块。 这些相当常见,因为美国政府购买的所有计算机都需要它们。然而,他们的能力各不相同。您需要一个支持远程证明的功能,它允许软件对其自身执行完整性检查。借助此功能,您可以编写可以强制执行数据销毁策略的软件。然而,我认为这个功能并没有被广泛使用。我的笔记本电脑有 TPM,但不支持此功能。

您还应该意识到,人们对“可信计算”存在很多敌意,因为它可以用来限制机器的功能。这侵犯了您随心所欲地处理您的财产的权利。 TPM 可能对公司或政府机器有意义,但对个人计算机则不然。

问题的其他方面(例如授予多个用户对数据的访问权限、要求多个用户获得对数据的访问权限)会更容易。

为多个用户加密数据通常是通过以下方式实现的:生成密钥,使用该“内容加密密钥”加密数据,然后使用属于的“密钥加密密钥”(可以是密码)加密该密钥(相对较小)。每个预期的接收者。

可以使用 Shamir 秘密共享,正如我在此处了解到的那样。


根据对问题的评论,尤其是“邮寄标签打印服务”的类比,恐怕我最初的答案并不真正相关。

遇到这样的情况,我只能寻求法律途径解决。禁止在合同中存储您的数据。如果值得起诉他们违反合同,那就起诉吧。

从密码学角度来说,我能想到的最好的办法就是在这样的“邮件列表”上添加“水印”,其中包含可以帮助我证明该列表的副本是由特定供应商披露的信息。知道水印的存在可能会阻止任何故意披露,并有助于在意外披露的情况下实现快速解决。这可以在记录中使用隐写技术以及在集合中使用假记录。

执行此操作的算法可能已经存在,但我对该领域并不熟悉。研究“数字水印”可能会有用。即使它只提供受保护的视频和音频的算法,也许这些算法可以适应其他媒体。

Executive summary: this isn't a realistic solution. Re-think the process so that "read-once" isn't necessary.

A few companies (Disappearing Inc. comes to mind, and they had at least one competitor) tried to make "self-destructing" email on general-purpose hardware in the late 90s. They spent millions of dot.com dollars to develop systems that didn't really work.

The only potential solution I know of is the use of a Trusted Platform Module. These are fairly common, as they are required in all computers bought by the US government. However, their capabilities vary. You'd need one that supported something called remote attestation, which allows software to perform integrity checks on itself. With this capability, you could write software that would enforce your data destruction policy. However, I don't think this feature is widely used. My laptop has a TPM, but it doesn't support this.

You should also be aware that there is a lot of hostility against "trusted computing," because it can be used to limit the functionality of a machine. This violates the right to do as you please with your property. TPMs might make sense for corporate or government machines, but not for personal computers.

Other aspects of your problem, such as granting multiple users access to the data, requiring multiple users to gain access to the data are easier.

Encrypting data for multiple users is typically achieved by generating a key, encrypting the data with that "content encryption key", then encrypting the key (which is relatively small) with a "key encryption key" (which could be a password) belonging to each intended recipient.

Requiring some number of users to enter a password can be done securely with Shamir Secret Sharing, as I learned here on SO.


Based on the comments on the question, especially the "mailing label printing service" analogy, I'm afraid my initial answer isn't really relevant.

In a case like that, I can only see a legal solution. Disallow storage of your data in the contract. If it's worth suing them for violating the contract, do so.

Cryptographically speaking, the best thing I could think of would be to "watermark" such a "mailing list" with information that would help me prove that a copy of the list was disclosed by a particular vendor. Knowing that a watermark exists might deter any deliberate disclosures, and could help leverage a fast settlement in the case of accidental disclosure. This could use steganographic techniques within records as well as fake records in the collection.

Algorithms for doing this might already exist, but I'm not familiar with the field. Researching "digital watermarks" might be useful. Even if it only turns up algorithms for protected video and audio, perhaps these could be adapted to work with other media.

原来分手还会想你 2024-08-11 12:32:50

您的方法存在几个问题。

  1. 如果您可以从任何应用程序读取数据,那么您就可以在任何地方保护数据。我认为这将违背任何“仅限一次访问”政策的目的。
  2. 要获得一个设备驱动程序来处理您的场景,您需要深入了解文件系统编程,这至少在 Windows 下并不是一件容易的事。即便如此,也很难强制执行一次性访问先决条件。
  3. 程序有不同的文件访问策略,这可能会打破您的假设。例如,应用程序可以打开一个文件一次以获取其大小,然后关闭并重新打开它以加载其数据。应该如何强制执行?您想限制“OpenFile”调用吗?您想限制“读取字节”调用吗?您想限制...在文件中跳跃吗?
  4. 当你的媒介被复制时,无论以何种方式,你都无法知道这一点。游戏行业多年来一直试图将游戏与原始 CD 绑定,但多年来都惨遭失败。

我认为,可行的是带有编码器/解码器的容器格式,或者类似的东西。 (请参阅 Windows7 中的 Bitlocker)这将保证您只能将数据解码一次到本地磁盘,然后删除介质上的容器(注意,首先检查介质是否可写,并将容器绑定到串行-介质的编号或名称,以便容器无法被复制)。

另一种可能性是使用单独的 USB 设备,您只能使用该设备一次来从中提取数据。那么您只需要在用户模式下使用 WinUSB 编写一次驱动程序。加密 USB 棒就使用这种方法。

但我真的认为这是一个坏主意,因为当接收者可以从介质中读取所有数据并将其安全地保存在其他地方时,您可以很容易地绕过任何反测量。

There are several problems with your approach.

  1. If you can read the data from any application, you can safe the data anywhere. I would think this would defeat the purpose of any 'only-one-access' policy.
  2. To get a device driver to handle your scenario, you would need deep knowledge of file-system-programming, which at least under windows is no easy undertaking. Even then, it would be hard to enforce the one time access prerequisite.
  3. Programs have different file-access strategies, which might break your assumptions. E.g. an application may open a file once to get its size, then close and reopen it, to load its data. How should this be enforced? Do you want to limit 'OpenFile' calls? do you want to limit 'read byte' calls? Do you want to limit ... jumping around in the file?
  4. When your medium gets copied, by whatever means, you have no way of knowing that. The games industry tries to bind the game to the original CD for years, but failed miserably for years.

I think, what would be feasible, would be a container format, with a encoder/decoder, or something like that. (See Bitlocker in Windows7) That would guarantee, that you can only decode the data once to a local disc and would then delete the container on your medium (beware, check first if the medium is writable, and bind the container to an serial-number or name of the medium so that the container cannot be copied).

Another possibility would be a separate USB device, which you can only use once to extract the data from it. Then you would only need to write a driver once in user mode with WinUSB. Encrypted USB-Sticks use this approach.

But I really think this is a bad idea, because you can very easily get around any counter measurement, when the receiving person can read all data from the medium and safe it anywhere else.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文