it-swarm-vi.com

Tại sao chúng ta không nên tự lăn?

Tại sao chúng ta không nên tạo các chương trình bảo mật của riêng mình?

Tôi thấy rất nhiều câu hỏi quanh đây về tiền điện tử tùy chỉnh và cơ chế bảo mật tùy chỉnh, đặc biệt là xung quanh việc băm mật khẩu.

Với ý nghĩ đó, tôi đang tìm kiếm một câu trả lời chính tắc, với các thuộc tính sau:

  • Dễ dàng cho một người mới hiểu.
  • Rõ ràng và rõ ràng trong tại sao tự lăn là một ý tưởng tồi.
  • Cung cấp các ví dụ mạnh mẽ.

Bắt buộc xkcd.

255
Polynomial

Bạn có thể tự lăn, nhưng có thể bạn sẽ phạm sai lầm bảo mật lớn nếu bạn không phải là chuyên gia về bảo mật/mật mã hoặc đã có sơ đồ của bạn được phân tích bởi nhiều chuyên gia. Tôi sẵn sàng đặt cược vào một chương trình mã hóa được biết đến công khai nguồn mở để mọi người cùng xem và phân tích. Nhiều mắt hơn có nghĩa là nhiều khả năng phiên bản hiện tại không có lỗ hổng lớn, trái ngược với thứ được phát triển nội bộ bởi những người không phải là chuyên gia.

Từ Phil Zimmermann's (người tạo PGP) Giới thiệu về Mật mã học (Trang 54) :

Khi tôi học đại học vào đầu những năm 70, tôi đã nghĩ ra thứ mà tôi tin là một chương trình mã hóa tuyệt vời. Một luồng số giả ngẫu nhiên đơn giản đã được thêm vào luồng plaintext để tạo bản mã. Điều này dường như sẽ cản trở bất kỳ phân tích tần số nào của bản mã, và sẽ không thể bị khóa ngay cả đối với các cơ quan tình báo chính phủ tài nguyên nhất. Tôi cảm thấy rất tự mãn về thành tích của mình.

Nhiều năm sau, tôi phát hiện ra sơ đồ tương tự này trong một số văn bản mã hóa giới thiệu và tài liệu hướng dẫn. Đẹp làm sao. Các nhà mật mã khác đã nghĩ về cùng một sơ đồ. Thật không may, sơ đồ đã được trình bày dưới dạng một bài tập về nhà đơn giản về cách sử dụng các kỹ thuật mật mã cơ bản để bẻ khóa nó một cách tầm thường. Quá nhiều cho kế hoạch tuyệt vời của tôi.

Từ kinh nghiệm khiêm tốn này, tôi đã học được cách dễ dàng rơi vào cảm giác an toàn sai lầm khi nghĩ ra một thuật toán mã hóa. Hầu hết mọi người không nhận ra khó khăn đến mức nào khi nghĩ ra một thuật toán mã hóa có thể chịu được một cuộc tấn công kéo dài và quyết tâm của một đối thủ tháo vát.

(Điều này câu hỏi có thêm thảo luận về trích dẫn ở trên.)

Nếu bạn không bị thuyết phục về "Đừng cuộn [Mật mã/bảo mật] của riêng bạn", thì có lẽ bạn không phải là chuyên gia và có nhiều sai lầm bạn có thể sẽ mắc phải.

Ứng dụng của bạn có mạnh mẽ chống lại:

  • Tấn công thời gian . Ví dụ: để các nano giây làm các khóa hoàn toàn xấu và các khóa xấu một phần mất cùng một lượng thời gian trong tập hợp để thất bại? Mặt khác, thông tin thời gian này có thể được khai thác để tìm khóa/mật khẩu chính xác.

  • Tấn công tầm thường tầm thường ; ví dụ: điều đó có thể được thực hiện trong vòng vài giây đến vài năm (khi bạn lo lắng về việc nó bị hỏng trong vòng một vài năm). Có lẽ ý tưởng về bảo mật của bạn có thể là cơ hội 1 trong một tỷ (1 000 000 000) để xâm nhập (điều gì sẽ xảy ra nếu ai đó có mạng bot thử vài tỷ lần?). Ý tưởng của tôi là nhắm đến thứ gì đó như 1 trong ~ 2128 (34 000 000 000 000 000 000 000 000 000 000 000), gần gấp mười triệu tỷ tỷ lần an toàn hơn và hoàn toàn nằm ngoài phạm vi đoán theo cách của bạn.

  • Tấn công vào tài khoản người dùng song song; ví dụ: bạn có thể băm mật khẩu với cùng một (hoặc tệ hơn là không) 'muối' trên tất cả các băm mật khẩu trong cơ sở dữ liệu giống như những gì đã xảy ra với băm bị rò rỉ LinkedIn băm.

  • Tấn công bất kỳ tài khoản cụ thể đơn giản. Có thể có một loại muối ngẫu nhiên duy nhất với mỗi mật khẩu được băm đơn giản (ví dụ: MD5/SHA1/SHA2), nhưng khi bạn có thể thử hàng tỷ mật khẩu có thể trên bất kỳ hàm băm nào mỗi giây, do đó, có thể sử dụng danh sách mật khẩu phổ biến, tấn công từ điển, v.v. chỉ mất một giây kẻ tấn công để bẻ khóa hầu hết các tài khoản. Sử dụng băm mật mã mạnh như bcrypt hoặc PBKDF2 để tránh hoặc tăng cường khóa băm thường xuyên theo một yếu tố phù hợp (thường là 10(3-8)).

  • Tấn công vào các số "ngẫu nhiên" có thể đoán/yếu. Có thể bạn sử dụng microtime/MT-Rand hoặc quá ít thông tin để tạo số giả ngẫu nhiên như Debian OpenSSL đã thực hiện vài năm trước .

  • Tấn công mà bỏ qua bảo vệ. Có thể bạn đã băm/nhập xác thực phía máy khách trong ứng dụng web và điều này được bỏ qua bởi người dùng thay đổi tập lệnh. Hoặc bạn có ứng dụng cục bộ mà máy khách cố chạy trong máy ảo hoặc tháo rời để thiết kế ngược lại/thay đổi bộ nhớ/hoặc bằng cách nào đó gian lận.

  • Các cuộc tấn công khác, bao gồm (nhưng không cố gắng trở thành một danh sách đầy đủ) CSRF , XSS =, SQL SQL , nghe lén mạng, phát lại các cuộc tấn công , Man in the Middle Tấn công , tràn bộ đệm , v.v. Bảo vệ tốt nhất rất nhanh chóng tóm tắt.

    • CSRF: yêu cầu mã thông báo CSRF được tạo ngẫu nhiên trên POST hành động; XSS: luôn xác thực/thoát khỏi đầu vào người dùng không tin cậy trước khi nhập vào cơ sở dữ liệu và hiển thị cho người dùng/trình duyệt.
    • SQLi: luôn sử dụng các tham số ràng buộc và giới hạn số lượng kết quả được trả về.
    • Nghe trộm: mã hóa lưu lượng mạng nhạy cảm.
    • Phát lại: đặt các lần duy nhất một lần duy nhất trong mỗi giao dịch.
    • MitM: Web of Trust/Giống như trang web đã truy cập lần cuối/Chứng chỉ do CA đáng tin cậy cấp.
    • Bộ đệm tràn: ngôn ngữ lập trình/thư viện an toàn/bảo vệ không gian thực thi/vv).

Bạn chỉ mạnh như liên kết khai thác yếu nhất của bạn. Ngoài ra, chỉ vì bạn không triển khai chương trình của riêng mình, điều đó không có nghĩa là chương trình của bạn sẽ được bảo mật, rất có thể người tạo ra những gì bạn đưa ra không phải là một chuyên gia hoặc tạo ra một kế hoạch yếu.

233
dr jimbob

Có một ngôi nhà trong khu vực của tôi với một sàn thực sự đẹp bên ngoài phòng gia đình tầng hai. Nó trông sưng lên, cho đến khi bạn đi bên dưới và xem nó được xây dựng như thế nào. Có vẻ như chủ nhà đã quyết định rằng anh ta không cần phải trả nhiều tiền cho một người xây dựng hoặc kiến ​​trúc sư để nói với anh ta cách xây dựng một sàn. Anh ta tự chế tạo nó và nó trông giống như một mạng nhện hỗn loạn của 2x4 bên dưới. Nó [~ # ~] có lẽ [~ # ~] sẽ ổn. Cá nhân, tôi không muốn mạo hiểm cuộc sống và chân tay vào một công việc xây dựng nghiệp dư như thế.

Tôi nghĩ rằng nếu bạn muốn phát triển một thuật toán để thực hiện mã hóa, bạn nên làm như vậy và có thời gian tốt về nó. Tôi không khuyên bạn nên sử dụng nó để ẩn các báo cáo ngân hàng trực tuyến của mình nhưng nếu bạn muốn mã hóa thư tình của bạn gái của bạn trên máy tính ở nhà, điều đó sẽ ổn nếu bạn cung cấp cho vợ bạn không phải là một nhà phân tích mật mã.

Có một câu chuyện trong Tiếng Anh Phòng Đen Mỹ * về Hải quân phát triển mật mã của riêng họ. Hải quân sẽ cho thấy hệ thống mật mã mới của họ, hài lòng với chính họ và Yardley, nhà phân tích của Quân đội, sẽ nhanh chóng phá mã, giải thích những gì họ đã làm sai. Họ sẽ đề nghị sửa mã nhưng Yardley chỉ ra rằng trong khi họ có thể khắc phục những điểm yếu cụ thể, nếu không có sự hiểu biết vững chắc, họ sẽ luôn gặp vấn đề. Hệ thống của họ về bản chất là thiếu sót. Nó giống như vá một mái nhà bị dột. Bạn có thể vá mãi mãi nhưng nước vẫn sẽ tìm đường vào. Nếu bạn không muốn bị ướt, mái nhà cần được xây dựng bởi một người biết nhiều hơn một chút về mái nhà.

Tôi đã bao giờ nói với bạn về ca phẫu thuật não tự làm mà tôi đã thực hiện trên người mẹ chồng quá cố của mình chưa? Mọi thứ diễn ra tốt đẹp cho đến khi cô đi và chết. Nghiêm túc mà nói, ít người trong chúng ta sẽ tin tưởng sức khỏe của mình cho một bác sĩ nghiệp dư; Bạn có thực sự muốn tin tưởng bí mật của bạn vào phần mềm nghiệp dư? Tôi ghét phải thừa nhận nó nhưng tôi mua vé số cứ sau vài tháng. Tôi hoàn toàn mong đợi để mất nhưng khoản thanh toán tiềm năng là rất lớn. Tôi có thể chơi tỷ lệ cược và có thể tôi sẽ đi ra phía trước. Nếu tôi không dạy, tôi sẽ không thành công. Tại sao chơi tỷ lệ cược trên mã hóa? Xuất chi không có.

Trân trọng,/Bob Bryan

  • Đề xuất: Herbert O. Yardley, Hồi The American Black Chamber Nhận - Một cuốn sách thú vị ngày nay như khi nó được viết vào năm 1931. Hồi Phòng Mỹ đen chứa đầy những câu chuyện hay, cũng như những mô tả thẳng thắn về những thành công của Yardley trong phân tích mật mã. Đó là một cuốn sách bán chạy nhất vào năm 1932 - ở nước ngoài cũng như trong nước. Từ NSA: Đánh giá Trân Châu Cảng - Phòng Đen
63
Bob Bryan

Bruce Scheier đã viết trở lại năm 1998:

Bất cứ ai, từ người nghiệp dư không biết gì nhất đến người viết mật mã giỏi nhất, đều có thể tạo ra một thuật toán mà chính anh ta không thể phá vỡ. Nó thậm chí không khó. Điều khó là tạo ra một thuật toán mà không ai có thể phá vỡ, ngay cả sau nhiều năm phân tích. Và cách duy nhất để chứng minh điều đó là đưa thuật toán vào nhiều năm phân tích bởi các nhà mật mã giỏi nhất xung quanh.

Cory Doctorow đã đặt tên cho khái niệm này là "Định luật Schneier" trong năm 2004 bài phát biể :

Bất kỳ ai cũng có thể phát minh ra một hệ thống bảo mật thông minh đến mức cô ấy hoặc anh ấy không thể nghĩ ra cách phá vỡ nó.

Theo dõi, này , một lần nữa từ Schneier:

Khi ai đó trao cho bạn một hệ thống bảo mật và nói: "Tôi tin rằng điều này là an toàn", điều đầu tiên bạn phải hỏi là "Bạn là ai vậy?" Chỉ cho tôi những gì bạn đã phá vỡ để chứng minh rằng sự khẳng định của bạn về bảo mật hệ thống có ý nghĩa gì đó.

Phil Zimmerman cũng đã viết trong bài báo PGP gốc :

Khi tôi học đại học vào đầu những năm bảy mươi, tôi đã nghĩ ra thứ mà tôi tin là một chương trình mã hóa tuyệt vời. Một luồng số giả ngẫu nhiên đơn giản đã được thêm vào luồng plaintext để tạo bản mã. Điều này dường như sẽ cản trở bất kỳ phân tích tần số nào của bản mã, và sẽ không thể bị khóa ngay cả đối với các cơ quan tình báo tài nguyên nhất của Chính phủ. Tôi cảm thấy rất tự mãn về thành tích của mình. Vì vậy, chắc chắn gà.

Nhiều năm sau, tôi phát hiện ra sơ đồ tương tự này trong một số văn bản mã hóa giới thiệu và tài liệu hướng dẫn. Đẹp làm sao. Các nhà mật mã khác đã nghĩ về cùng một sơ đồ. Thật không may, sơ đồ đã được trình bày dưới dạng một bài tập về nhà đơn giản về cách sử dụng các kỹ thuật mật mã cơ bản để bẻ khóa nó một cách tầm thường. Quá nhiều cho kế hoạch tuyệt vời của tôi.

59
tylerl

Bài viết gốc yêu cầu một ví dụ:

Babington Plot là một câu chuyện hay về một hệ thống mật mã xấu gây ra vấn đề. Mary Queen of Scots đã bị giam giữ bởi chị họ Nữ hoàng Elizabeth I và đang liên lạc với mọi người ở bên ngoài thông qua các chữ cái được mã hóa. Bảng chữ cái đã được thay thế bằng một loại tiền điện tử của squiggles, hình tròn và hình tam giác có thêm chữ cái được gán cho các chữ cái phổ biến, như e, t, i và o để không thể tìm thấy ý nghĩa của các chữ cái bằng cách phân tích tần số. Họ cũng đã thêm một vài ký tự null được bỏ qua trong quá trình giải mã để loại bỏ các nhà phân tích. Vấn đề là Nữ hoàng có một nhân viên mật mã rất có năng lực trong đội ngũ nhân viên của mình trong người của Thomas Phelippes, người có thể giải mã các tin nhắn khi chúng bị chặn.

Khi mọi thứ tiến triển, Mary đi cùng với một âm mưu để cô trốn thoát và chiếm lấy ngai vàng. Khi các đặc vụ của Queen Queen chặn lá thư cuối cùng từ Mary trước khi chuyển nó, họ đã thêm một câu được mã hóa để hỏi tên của những người liên quan đến cốt truyện để họ có thể được khen thưởng đúng cách. Phóng viên Mary Mary đã trả lời một cách nghiêm túc và các đặc vụ của Nữ hoàng đã khiến mọi người liên quan bị xử tử.

Khi con tôi còn nhỏ, tôi sẽ gửi cho chúng mật mã bằng bữa trưa của chúng (có khóa (sử dụng mật mã Vernam)). Nói chung, họ là những trò đùa nhưng họ không bao giờ quan trọng. Trong trường hợp như vậy, cuộn của riêng bạn là tốt. Nếu bạn đang âm mưu lật đổ Nữ hoàng Anh (hoặc Shah của Iran hoặc Thug-ocality cải cách từ từ ở Myanmar), tôi sẽ đề nghị bạn đảm bảo rằng những gì bạn đang sử dụng không thể được giải mã dễ dàng. Như Bruce Schneier đã nói , bất kỳ ai cũng có thể tìm ra một hệ thống mật mã mà họ không thể giải mã được, nhưng đến với ai đó không ai có thể giải mã được thì khó hơn.

45
Bob Bryan

Tôi sẽ đưa ra một ví dụ về điều gì đó đã xảy ra ở đây nơi tôi làm việc. Một đồng nghiệp của tôi chịu trách nhiệm thiết kế một hệ thống lưu trữ mật khẩu (câu chuyện dài, đừng hỏi) cho các tài khoản FTP của công ty. Tôi đã được yêu cầu tiếp quản, và điều đầu tiên tôi thấy là:

public string Encrypt(string rawText)
{
    // homebrew code here
}
public string Decrypt(string encrypted)
{
    // homebrew code here
}

Tôi lập tức xé chúng ra, thay thế chúng bằng các cuộc gọi thư viện mật mã tiêu chuẩn - và khi tôi được hỏi, tôi đã trả lời:

"Bạn không bao giờ cuộn thói quen mã hóa của riêng bạn."

Đồng nghiệp của tôi đã chiến đấu với tôi về điều này trong nhiều giờ. Anh ta đã dành rất nhiề thời gian cho nó, làm cho nó hoàn hảo, để kẻ tấn công không thể có thể có cách phá vỡ nó . Tại một thời điểm, họ thậm chí còn nói: "Điều này an toàn hơn AES256, vì không ai biết nó hoạt động như thế nào".

Vào thời điểm đó, tôi biết hai điều:

  • Đồng nghiệp của tôi là một ví dụ hoàn hảo về hiệu ứng Dunning Kruger (thiếu kiến ​​thức về một chủ đề khiến nó có khả năng đánh giá quá cao khả năng của chính họ)
  • Đồng nghiệp của tôi đã phải được sửa chữa. Không chỉ vì chúng "sai", mà bởi vì chúng chịu trách nhiệm về kiến ​​trúc khác hệ thống, và tôi không muốn chúng giữ mã hóa sản xuất tại nhà.

Vì vậy, tôi để mã sang một bên. Và thay vào đó, tôi đã thử phá mã theo thói quen bằng cách gọi hàm Encrypt () và kiểm tra đầu ra. Tôi là người mới - Tôi không phải là nhà phân tích mật mã - nhưng tôi chỉ mất 4 giờ. Tôi đã chứng minh vết nứt cho họ, hướng dẫn họ qua các bước của tôi và nhắc lại: Không bao giờ cuộn mã hóa của riêng bạn. Hy vọng họ sẽ thuộc nằm lòng và không bao giờ làm điều đó một lần nữa.

Vì vậy, nó sôi lên:

  1. Mức độ tin cậy của bạn đối với tính bảo mật của mã hóa của bạn có không dựa trên mức độ an toàn thực sự của nó.
  2. Không bao giờ cuộn mã hóa của riêng bạn (không thể lặp lại thường xuyên đủ ...)
13
Kevin

Trong mật mã, bạn không chỉ có một đối thủ tấn công bạn theo cách bạn mong đợi. Đây là những gì làm cho nó khó để lý luận về, bởi vì bạn phải nghĩ về MỌI THỨ hoàn toàn.

Nhưng thực sự, không ai có thể vượt qua mọi đối thủ có thể. Điều tốt nhất chúng ta có thể làm là sử dụng kiến ​​thức phổ biến và nghiên cứu hiện có càng nhiều càng tốt và thực hiện các bước bé để xây dựng từ đó, tấn công vectơ bằng vectơ tấn công.

Đây là cách mà rất nhiều vấn đề bên bờ vực khả năng của con người được tiếp cận, có thể là nghiên cứu trong vật lý hoặc chơi cờ ở cấp độ cao nhất.

Trong các lĩnh vực này, bạn cũng có thể bỏ qua những gì người khác đang làm và đưa ra các chiến lược và lý thuyết của riêng bạn, và nếu bạn gặp đối thủ lành nghề đầu tiên, bạn sẽ bị xóa sổ bởi tình trạng nghệ thuật theo nhiều cách mà bạn có thể đếm được.

TL; DR
[.__.] Con người quá ngu ngốc khi làm mật mã một mình.

13
mschwaig

Nói chung, không thể đảm bảo rằng ai đó thiết kế một hệ thống mật mã sẽ không rời khỏi công ty mà nó được tạo ra và sử dụng kiến ​​thức về thiết kế đó để gây bất lợi cho chủ nhân cũ của họ, ngoại trừ bằng cách thiết kế hệ thống mật mã theo cách mà bất kỳ kiến thức như vậy một kẻ thù có thể có được có thể trở nên vô dụng.

Nếu một người có một hệ thống mật mã an toàn ngay cả với những kẻ tấn công biết tất cả mọi thứ trừ khóa và một người thay đổi khóa thành giá trị được tạo ngẫu nhiên mới, thì hệ thống sẽ được bảo mật trước mọi kẻ tấn công không có khóa mới. Ngay cả khi những kẻ tấn công có đủ thông tin để thỏa hiệp hệ thống trước khi khóa được thay đổi, chúng sẽ không thể phá vỡ hệ thống sau đó.

Trừ khi một hệ thống cần bảo vệ dữ liệu có giá trị bất thường, có lẽ không quá khó để thiết kế một hệ thống mật mã đủ tốt để nếu không có kiến ​​thức nội bộ, chi phí bẻ khóa sẽ vượt quá bất kỳ giá trị nào có thể đạt được bằng cách làm như vậy. Không phải vì thiết kế tiền điện tử tốt là dễ dàng, mà bởi vì hầu hết các hệ thống không được sử dụng để bảo vệ bất cứ thứ gì có giá trị đối với kẻ tấn công (ngay cả khi một nhà mật mã lành nghề có thể dễ dàng phá vỡ hệ thống trong 58 phút, điều đó sẽ không nhiều rủi ro trừ khi giá trị của thông tin đó đối với kẻ tấn công sẽ vượt quá chi phí thời gian của nhà mật mã học).

Tuy nhiên, việc thiết kế một hệ thống để có thể trở nên mạnh mẽ đối với người có dữ liệu nội bộ, tuy nhiên, khó khăn hơn nhiều và có rất ít người có đủ chuyên môn để thiết kế một hệ thống có thể - bằng cách thay đổi khóa - được thực hiện mạnh mẽ bằng cách một người có cả kiến ​​thức bên trong về thiết kế và chuyên môn về mật mã. Một chuyên gia mật mã không có kiến ​​thức nội bộ có thể phải kiểm tra hàng trăm hoặc hàng ngàn lỗi tiềm ẩn mà một nhà thiết kế có thể mắc phải, nhưng kiến ​​thức nội bộ có thể cho phép người đó xác định và khai thác sai lầm ngay lập tức.

1
supercat

Trên thực tế, hãy cuộn tiền điện tử của riêng bạn, sau đó ném nó đi.

Crypto Fails gọi ra, thật khó để nói rằng bạn không thể viết bất kỳ mã hóa nào cả. Vấn đề chính là không lấy mã đó và sử dụng nó ở bất cứ đâu (trong phần mềm được phát hành).

Bạn chắc chắn nên cho nó một shot và sử dụng nó như một kinh nghiệm học tập. Thậm chí tốt hơn nếu bạn là bạn bè với một nhà phân tích mật mã và có thể nhận phản hồi của họ về những gì bạn đã viết. Nếu họ đáng muối, họ cũng sẽ nói với bạn rằng đừng sử dụng mã trong cuộc sống thực, nhưng họ sẽ có thể cung cấp cho bạn một số thông tin giúp bạn học hỏi và phát triển.

0
NH.