Không có kiến ​​thức lưu trữ mã? [đóng cửa]


28

Trước những tiết lộ gần đây về việc giám sát dữ liệu rộng rãi của chính phủ được lưu trữ bởi các nhà cung cấp dịch vụ trực tuyến, các dịch vụ không có kiến ​​thức là tất cả những cơn thịnh nộ hiện nay.

Dịch vụ không kiến ​​thức là một dịch vụ trong đó tất cả dữ liệu được lưu trữ được mã hóa bằng khóa không được lưu trữ trên máy chủ. Mã hóa và giải mã xảy ra hoàn toàn ở phía máy khách và máy chủ không bao giờ nhìn thấy dữ liệu văn bản gốc hoặc khóa. Do đó, nhà cung cấp dịch vụ không thể giải mã và cung cấp dữ liệu cho bên thứ ba, ngay cả khi họ muốn.

Để đưa ra một ví dụ: SpiderOak có thể được xem là phiên bản không có kiến ​​thức của Dropbox.

Là lập trình viên, chúng tôi phụ thuộc rất nhiều vào và tin tưởng một số dữ liệu nhạy cảm nhất của chúng tôi - mã của chúng tôi - vào một loại nhà cung cấp dịch vụ trực tuyến cụ thể: nhà cung cấp dịch vụ lưu trữ mã (như Bitbucket, Assembla, v.v.). Tất nhiên tôi đang nói về các kho lưu trữ riêng ở đây - khái niệm về kiến ​​thức không có ý nghĩa đối với các kho lưu trữ công cộng.

Câu hỏi của tôi là:

  1. Có bất kỳ rào cản công nghệ nào trong việc tạo ra một dịch vụ lưu trữ mã kiến ​​thức không? Ví dụ, có điều gì đó về các giao thức mạng được sử dụng bởi các hệ thống kiểm soát phiên bản phổ biến như SVN, Mercurial hoặc Git sẽ gây khó khăn (hoặc không thể) thực hiện một sơ đồ trong đó dữ liệu được truyền thông giữa máy khách và máy chủ được mã hóa với Một khóa mà máy chủ không biết?

  2. Có bất kỳ dịch vụ lưu trữ mã kiến ​​thức không tồn tại ngày nay?


1
Không có mã hóa đồng cấu , tôi không thấy làm thế nào một trang web lưu trữ mã kiến ​​thức bằng không có thể cung cấp bất kỳ loại lợi ích nào đối với phiên bản thả xuống không có kiến ​​thức. Tôi không tin bất cứ ai đã đưa ra một chương trình như vậy vừa an toàn (nghĩa là đủ an toàn để các chuyên gia tin tưởng) và đủ nhanh để có thể sử dụng được.
Brian

2
@AresresF. Tôi chỉ có thể giả sử SpiderOak có nghĩa là thế hệ diff xảy ra trên máy khách, máy chủ lưu trữ diffs được mã hóa và sau đó ứng dụng diff-to-base xuất hiện lại trên máy khách khi diff và base được mã hóa. Tôi đồng ý rằng ngôn ngữ của họ rất không rõ ràng.
apsillers

2
@apsillers: Hoặc bạn có thể cố tình nhét nội dung đó vào một tệp và sử dụng nó để xác định chính tệp đó (ví dụ: nếu ai đó đang cố sử dụng mã hóa để che giấu vi phạm bản quyền).
Brian

4
Đó không phải là điều tôi có bất kỳ kinh nghiệm nào, nhưng tôi có thể tưởng tượng một rào cản công nghệ có thể có để có một dịch vụ lưu trữ mã kiến ​​thức bằng không: tất cả người dùng có cần biết / sử dụng cùng một khóa không? Và nếu đó là trường hợp, cơ chế xác thực sẽ đảm bảo mức độ truy cập khác nhau của người dùng là gì?
CB

2
@gnat: Tôi không yêu cầu đề xuất. Tôi chỉ đang hỏi liệu một dịch vụ thuộc loại tôi mô tả có tồn tại không. Sự tồn tại của một dịch vụ như vậy sẽ cung cấp bằng chứng cho thấy các rào cản công nghệ mà tôi hỏi trước đó trong câu hỏi là quá sức.
HC4 - phục hồi Monica

Câu trả lời:


3

Bạn có thể mã hóa từng dòng riêng biệt. Nếu bạn có thể đủ khả năng để rò rỉ tên tệp và độ dài dòng gần đúng và số dòng trên đó xảy ra thay đổi dòng, bạn có thể sử dụng một cái gì đó như thế này:

https://github.com/ysangkok/line-encryptor

Vì mỗi dòng được mã hóa riêng biệt (nhưng có cùng khóa), các thay đổi được tải lên sẽ (như thường) chỉ liên quan đến các dòng có liên quan.

Nếu hiện tại nó không đủ tiện lợi, bạn có thể tạo hai kho Git, một với bản rõ và một với bản mã. Khi bạn cam kết trong kho lưu trữ bản rõ (là cục bộ), một hook hook có thể lấy diff và chạy nó thông qua bộ mã hóa dòng được tham chiếu ở trên, sẽ áp dụng nó vào kho lưu trữ bản mã. Các thay đổi kho lưu trữ bản mã sẽ được cam kết và tải lên.

Bộ mã hóa dòng ở trên là bất khả tri SCM, nhưng có thể đọc các tệp khác biệt thống nhất (của bản rõ) và mã hóa các thay đổi và áp dụng chúng cho bản mã. Điều này làm cho nó có thể sử dụng được trên bất kỳ SCM nào sẽ tạo cho bạn một sự khác biệt thống nhất (như Git).


Bạn không thể sử dụng git smudge-clean cho việc này sao?
Svick

@svick: Bạn có thể, nhưng bằng cách đó, tôi không thấy cách bạn sẽ cho phép tránh mã hóa lại toàn bộ tập tin một cách độc đáo. Nhưng tất nhiên, mã này không quan trọng lắm vì kích thước tệp nhỏ. Nhưng không cần phải có "bộ mã hóa dòng", bạn chỉ cần sử dụng bất kỳ công cụ mã hóa nào.
Janus Troelsen

Sẽ không có nhiều mẫu văn bản (với cấu trúc đã biết) có thể giúp tấn công khóa dễ dàng hơn không? Mỗi dòng trống sẽ mã hóa giống nhau. Mọi sự khởi đầu và kết thúc của một javadoc đều giống nhau. Bây giờ bạn đã biết văn bản rõ ràng và văn bản mật mã cho một số đoạn mã có thể được sử dụng. Điều này có thể sẽ không hữu ích đối với bất kỳ ai ngoài những người có sở thích (bất kỳ ai có loại tiền điện tử được đào tạo hoặc đủ sức mạnh tính toán có thể phá vỡ nó với đủ nỗ lực).

@MichaelT: Không, vì IV. Hãy tự mình thử :) Sử dụng triển khai được liên kết, mã hóa dòng <IV>,<ciphertext>.
Janus Troelsen

1
@svick: Các dòng được mã hóa riêng lẻ. Nếu bạn thay đổi một dòng, toàn bộ dòng sẽ được mã hóa lại, nhưng với IV mới (như mọi khi). Nhưng phần còn lại của tập tin sẽ không được chạm vào! Mã hóa mang tính quyết định, nhưng IV cũng là đầu vào và chúng được chọn ngẫu nhiên.
Janus Troelsen

1

Tôi không nghĩ có bất kỳ rào cản nào - hãy xem xét SVN, những gì được gửi đến máy chủ để lưu trữ là đồng bằng giữa phiên bản mã trước và hiện tại của mã - vì vậy bạn thay đổi 1 dòng, chỉ dòng đó được gửi đến máy chủ. Sau đó, máy chủ 'mù quáng' lưu trữ nó mà không thực hiện bất kỳ kiểm tra dữ liệu nào. Nếu bạn đã mã hóa delta và gửi nó thay vào đó, sẽ không có tác động đến máy chủ, thực tế bạn thậm chí sẽ không cần phải sửa đổi máy chủ.

Có một số bit khác có thể quan trọng, chẳng hạn như các thuộc tính dữ liệu meta không dễ mã hóa - chẳng hạn như loại mime - nhưng các bit khác có thể được mã hóa, ví dụ như các nhận xét trong nhật ký lịch sử, miễn là bạn biết bạn phải giải mã chúng trên khách hàng để xem. Tôi không chắc chắn nếu cấu trúc thư mục sẽ hiển thị, tôi nghĩ rằng nó sẽ không hiển thị do cách SVN lưu trữ các thư mục, nhưng có thể tôi đã sai. Điều này có thể không quan trọng với bạn nếu nội dung được an toàn tuy nhiên.

Điều này có nghĩa là bạn không thể có một trang web với các tính năng xem mã khác nhau, không có trình duyệt kho lưu trữ phía máy chủ hoặc trình xem nhật ký. Không có mã khác, không có công cụ đánh giá mã trực tuyến.

Một cái gì đó như thế này đã tồn tại, đến một lúc nào đó, Mozy lưu trữ dữ liệu của bạn được mã hóa bằng khóa riêng của bạn (bạn có thể sử dụng riêng của họ và họ tạo ra tiếng ồn về "nếu bạn mất khóa của chính mình, quá tệ, chúng tôi không thể khôi phục dữ liệu của bạn cho bạn ", nhưng đó là nhắm mục tiêu nhiều hơn vào người dùng phổ biến). Mozy cũng lưu trữ lịch sử các tệp của bạn, vì vậy bạn có thể truy xuất các phiên bản trước đó. Trường hợp rơi xuống là việc tải lên diễn ra thường xuyên, không đăng ký khi bạn muốn và tôi tin rằng nó sẽ loại bỏ các phiên bản cũ khi bạn hết dung lượng lưu trữ. Nhưng khái niệm là có, họ có thể sửa đổi nó để cung cấp kiểm soát nguồn an toàn bằng hệ thống hiện có của họ.


Re: "Điều này có nghĩa là bạn không thể có một trang web với các tính năng xem mã khác nhau, không có trình duyệt kho lưu trữ phía máy chủ hoặc trình xem nhật ký. Không có mã khác, không có công cụ đánh giá mã trực tuyến." - Bạn vẫn có thể có những thứ này nếu logic ứng dụng nằm trong JS phía máy khách và nó khiến bạn nhập mật khẩu / khóa của bạn (nhưng không gửi nó đến máy chủ), phải không?
HC4 - phục hồi Monica

Vâng, nó có thể .... Bất cứ điều gì sẽ miễn là nó biết rằng nó đang nhận dữ liệu được mã hóa qua mạng. Đó chỉ là một hạn chế rõ ràng của máy chủ rằng nó không thể giải mã dữ liệu.
gbjbaanb

1

Tôi ghét phải làm một trong những điều này 'điều này sẽ không hoàn toàn trả lời câu hỏi của bạn' .. nhưng ..

Tôi có thể nghĩ về hai giải pháp sẵn sàng để giải quyết những lo lắng này.

  1. Lưu trữ một máy chủ Git riêng trên của riêng bạn. Sau đó đặt máy chủ đó lên VPN mà bạn cấp cho các thành viên trong nhóm của mình quyền truy cập. Tất cả thông tin liên lạc đến và từ máy chủ sẽ được mã hóa và tất nhiên bạn có thể mã hóa máy chủ ở cấp độ HĐH.

  2. BitSync cũng nên thực hiện thủ thuật này. Mọi thứ sẽ được mã hóa, và trong một mạng lưới khổng lồ sẽ có sẵn từ bất cứ đâu. Có thể thực sự là một ứng dụng thực sự tốt của tất cả công nghệ BitCoin / BitMessage / BitSync này ..

Cuối cùng, những người ở tại https://security.stackexchange.com/ có thể có một số thông tin chi tiết hơn.


Về BitSync: bạn có gợi ý rằng nó được sử dụng để thay thế cho hệ thống kiểm soát phiên bản hoặc bằng cách nào đó được sử dụng cùng với hệ thống kiểm soát phiên bản không? Nếu trước đây, thì chắc chắn, nhưng điều đó không thú vị lắm. Tôi cũng có thể chia sẻ các tệp qua SpiderOak và nó sẽ được tập trung, nhưng vẫn không có kiến ​​thức. Nếu sau này thì thế nào?
HC4 - phục hồi Monica

1
@ HighCommander4 Không thử, nhưng không phải lý do nào để nó không hoạt động .. Bạn không thể thiết lập đồng bộ hóa để chia sẻ thư mục git đã khởi tạo của mình, sau đó chỉ cần làm bình thường 'git push ./syncedFolderActingAsServer/MyAwesomeProject/src/'? Bạn cũng có thể làm quyền cấp git, v.v. ai đó nên thử cái này!
Vịt cao su

1

Theo tôi hiểu, cách thức git pullhoạt động là máy chủ gửi cho bạn một tệp gói chứa tất cả các đối tượng mà bạn muốn, nhưng hiện tại không có. Và ngược lại cho git push.

Tôi nghĩ rằng bạn không thể làm điều đó trực tiếp như thế này (vì điều này có nghĩa là máy chủ phải hiểu các đối tượng). Thay vào đó, những gì bạn có thể làm là để máy chủ hoạt động chỉ với một loạt các tệp gói được mã hóa.

Để làm pull, bạn tải xuống tất cả các tệp gói đã được thêm từ lần cuối cùng của bạn pull, giải mã chúng và áp dụng cho repo git của bạn. Để làm push, trước tiên bạn phải làm pull, để bạn biết trạng thái của máy chủ. Nếu không có xung đột, bạn tạo một tệp gói với các thay đổi của mình, mã hóa nó và tải nó lên.

Với phương pháp này, bạn sẽ kết thúc với số lượng lớn các tệp gói nhỏ, sẽ khá kém hiệu quả. Để khắc phục điều đó, bạn có thể tải xuống một loạt các tệp gói, giải mã, kết hợp chúng thành một tệp gói, mã hóa và tải chúng lên máy chủ, đánh dấu chúng là một thay thế cho chuỗi đó.

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.