Khoa học máy tính lý thuyết liên quan đến bảo mật như thế nào?


11

Khi tôi nghĩ về phần mềm không an toàn, tôi nghĩ rằng nó "quá hữu ích" và có thể bị kẻ tấn công lạm dụng. Vì vậy, trong một ý nghĩa bảo mật phần mềm là quá trình làm cho phần mềm ít hữu ích hơn. Trong Khoa học máy tính lý thuyết, bạn không làm việc với thế giới thực. Vì vậy, có bất kỳ mối quan tâm bảo mật khi làm việc với lý thuyết thuần túy? Hoặc mặt khác của đồng tiền, liệu Khoa học máy tính lý thuyết có ảnh hưởng đến thế giới thực của con người bị hack không? Nếu vậy, chủ đề bảo mật nào được coi là Lý thuyết?


9
Quan điểm của Lý thuyết CS được trình bày là chủ quan và rất dễ tranh cãi và cũng không bắt buộc phải đặt ra câu hỏi. Câu hỏi dường như tập trung đặc biệt vào hack, vốn là một chủ đề rộng lớn và tự nó (bao gồm tất cả các kỹ thuật kỹ thuật xã hội) và không gần với những gì "an toàn" đòi hỏi. Vì những lý do này, tôi đã đánh giá thấp. Tuy nhiên, tôi cảm thấy câu hỏi đến từ một nơi tốt và có một số khía cạnh thú vị cho nó vì vậy tôi đã trả lời dưới đây.
Ross Snider

Câu trả lời:


20

Theo một nghĩa nào đó, trực giác của bạn rằng "sự không an toàn" là do phần mềm "quá hữu ích" là chính xác. Có một tài liệu lý thuyết lớn và đang phát triển về "quyền riêng tư khác biệt" chính thức hóa trực giác của bạn. Xem ví dụ, tại đây: Research.microsoft.com/en-us/projects/databaseprivacy/dwork.pdf

Ở đây, chúng tôi nghĩ rằng đầu vào của thuật toán là "cơ sở dữ liệu" và thuật toán là "không an toàn" nếu nó tiết lộ quá nhiều thông tin về bất kỳ dữ liệu nào của một người trong cơ sở dữ liệu. Một thuật toán là - riêng tư khác biệt nếu đầu ra của thuật toán không phụ thuộc nhiều vào bất kỳ một đầu vào nào: cụ thể, việc thay đổi một mục nhập trong cơ sở dữ liệu đầu vào chỉ nên thay đổi xác suất của bất kỳ đầu ra nào của thuật toán bằng nhiều nhất là một hệ số.e εϵeϵ

Tất nhiên, làm cho một thuật toán riêng tư làm cho nó ít hữu ích hơn: một thuật toán riêng tư khác biệt tạo ra các đầu ra thậm chí không phải là một chức năng của các đầu vào! Nhưng hóa ra bạn có thể thử và cân bằng cẩn thận sự đánh đổi giữa quyền riêng tư và tiện ích và có thể có được các thuật toán rất riêng tư mà vẫn rất hữu ích.0


14

Trong một số cách:


Tôi thực sự không tin rằng bạn đã từng tìm thấy một lỗ hổng, vá một đoạn mã hoặc thậm chí đã nhìn thấy hoạt động bên trong của một lỗ hổng trong thế giới thực.
The Rook

8
Sử dụng OllyDbg, tôi đã vá lỗi ddi gdi của mình để sửa lỗ hổng con trỏ (thứ hai) (rõ ràng là không có mã nguồn) trước bản vá thứ ba của Microsoft. Một lần nữa sử dụng OllyDbg, tôi đã vá một trình giả lập nguồn đóng để làm cho nó gian lận bằng chứng cho (một cách đáng xấu hổ) một cuộc thi Pokemon. Tôi đã tìm thấy 0 ngày trong một dự án webcam và đã đạt điểm cao hợp lý trên một số lượng lớn các chiến tranh (bao gồm cả Blacksun, có bật ASLR và PaX). Tôi sẽ không đề cập đến một số điều bất chính hơn tôi đã làm .... Nhún vai; Tại sao nó có vấn đề nếu tôi có hoặc không có? Xin đừng ngọn lửa.
Ross Snider

13
@ The Rook: Nếu bạn tin rằng danh sách của Ross có ít kết nối với thực tế bảo mật phần mềm, thì hãy nói như vậy. Thậm chí có thể đưa ra một số ví dụ sẽ hữu ích, hoặc thêm câu trả lời chi tiết của riêng bạn vào việc nghiên cứu bảo mật TCS cách xa thực tiễn bảo mật thực tế (mà tôi nghĩ sẽ rất thú vị khi đọc). Nhưng không cần phải hạ bệ Ross.
Joshua Grochow


10

Có rất nhiều động lực trong thế giới thực để nghiên cứu các thuật toán phát trực tuyến đến từ phát hiện xâm nhập mạng. Bài viết dưới đây sử dụng thuật toán phát trực tuyến cho entropy theo kinh nghiệm để phát hiện sự bất thường trong lưu lượng mạng của bạn.

Yu Gu, Andrew McCallum và Don Towsley. Phát hiện sự bất thường trong lưu lượng mạng bằng cách sử dụng ước tính entropy tối đa. Trong IMC '05: Kỷ yếu hội thảo ACM SIGCOMM lần thứ 5 về đo lường Internet, trang 1 Lọ6, 2005


8

Không giống như các câu trả lời khác, điều này phù hợp hơn với "những điều chúng ta nên lo lắng khi nói điều gì đó là" an toàn có thể chứng minh được ", trái ngược với những nơi mà TCS đã được sử dụng trong bảo mật. Vì vậy, nó giải quyết câu hỏi đầu tiên về mối quan tâm bảo mật khi làm việc với lý thuyết.

Như tin tặc nói, kết quả lý thuyết thường tiếp tuyến với an ninh trong thế giới thực. Kiểu tranh luận này đã được Alfred Menezes và Neal Koblitz đưa ra nhiều lý thuyết, khoa học và chính xác hơn trong loạt bài viết ' Cái nhìn khác ' của họ (cảnh báo: trang web có vẻ hơi đối đầu với tôi, nhưng tôi nghĩ rằng ý tưởng cơ bản của việc đặt câu hỏi giả định là rất quan trọng). Họ chỉ ra những điểm yếu trong các giả định tiêu chuẩn về mật mã, thậm chí trong các bài báo chuyên đề.

Một số ví dụ (trích dẫn / diễn giải một vài điểm từ trang web của họ):

  1. Một định lý bảo mật là có điều kiện - nó giả định tính hấp dẫn của một số vấn đề toán học.

  2. Thông thường, giả định về độ hấp dẫn được đưa ra cho một vấn đề phức tạp và có thể xảy ra: trong một số trường hợp, vấn đề này tương đương tầm thường với vấn đề phân tích mật mã cho giao thức có bảo mật được "chứng minh".

  3. Đôi khi một bằng chứng có khoảng cách độ kín lớn, nhưng kích thước tham số vẫn được khuyến nghị như thể bằng chứng đã được thắt chặt. Trong những trường hợp như vậy, bằng chứng thường đưa ra một giới hạn thấp hơn vô dụng về thời gian chạy của một cuộc tấn công thành công. Hơn nữa, một kết quả tiệm cận không nhất thiết cung cấp bất kỳ sự đảm bảo nào về bảo mật cho các tham số trong phạm vi được sử dụng trong thực tế.

  4. Một định lý bảo mật sử dụng một mô hình bảo mật nhất định. Một số cuộc tấn công nhất định - đặc biệt là các cuộc tấn công kênh bên - rất khó để mô hình hóa, và các mô hình đã được đề xuất là không đủ.


6

Các định lý định lý đã được sử dụng ở một mức độ nào đó để chứng minh tính đúng đắn của phần mềm, phần cứng và giao thức. Xem, ví dụ, ở đây hoặc ở đây .

Vấn đề truyền dữ liệu theo cách không mong muốn thông qua các chương trình (do đó gây ra rò rỉ tiềm năng) đã được mô hình hóa về mặt lý thuyết bằng cách sử dụng khái niệm nhiễu (không); nhận được con trỏ ở đây .


3

Khả năng quyết định là một mối quan tâm trung tâm trong nghiên cứu ngôn ngữ lập trình. Đó là, nhiều nỗ lực đang được đầu tư vào việc xây dựng các ngôn ngữ lập trình chỉ chấp nhận mã thỏa mãn các thuộc tính nhất định. Các ngôn ngữ tĩnh điển hình chỉ cung cấp các đảm bảo yếu, như từ chối một chương trình nếu một số phương thức nhất định không tồn tại, nhưng hãy tưởng tượng nếu ngôn ngữ đó cũng có thể loại bỏ các chương trình, ví dụ, sử dụng không đúng cách, hoặc cố gắng đọc vượt ra khỏi cuối vùng nhớ. Rõ ràng là các vấn đề về tính quyết định xuất hiện nhanh chóng (kịch bản đơn giản nhất: xác định rằng trình biên dịch của bạn chỉ nên chấp nhận các chương trình chấm dứt), và chắc chắn, có những lo ngại về hiệu quả (trình kiểm tra kiểu ML có các trường hợp hàm mũ gấp đôi).

Trong mọi trường hợp, cộng đồng nghiên cứu PL rất quan tâm đến bảo mật (bạn có tin tưởng trình duyệt của mình chạy mã nước ngoài tùy ý không?!), Và câu hỏi của họ dẫn đến nhiều câu hỏi lý thuyết CS cổ điển.


Bất kỳ ngôn ngữ cấp cao thích hợp nào (đọc: khác với C [++]) không cung cấp cho người lập trình quyền kiểm soát truy cập bộ nhớ, vì vậy tôi sẽ xem xét vấn đề này được giải quyết.
Raphael

@Raphael: Cho rằng một lượng lớn phần mềm vẫn được viết bằng C và C ++, vấn đề này không thể được xem xét giải quyết. Hơn nữa, các kỹ thuật để giải quyết các cuộc tấn công tiêm mã trên Javascript, chẳng hạn, vẫn còn ở giai đoạn sơ khai. Có rất nhiều việc phải làm.
Dave Clarke

1
Việc một số môi trường nhất định bỏ qua các giải pháp hiện có (đôi khi vì lý do chính đáng) không làm cho vấn đề (ở đây: truy cập các địa chỉ bộ nhớ bị cấm) ít được giải quyết. Một số điều khó kiểm tra có thể dễ dàng bị phá vỡ bởi những bất biến thích hợp. Ví dụ, bạn có thể yêu cầu bằng chứng chính thức về việc chấm dứt từ lập trình viên của mình (cf Isabelle / HOL).
Raphael
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.