Nơi lưu trữ khóa riêng?

Nói rằng tôi muốn một số phần mềm của tôi được mã hóa. Ví dụ: thông tin đăng nhập cho cơ sở dữ liệu, v.v. Tôi cần lưu trữ các giá trị đó ở đâu đó, nhưng làm như vậy trong phần văn bản rõ ràng sẽ giúp kẻ tấn công dễ dàng truy cập trái phép.

Tuy nhiên, nếu tôi mã hóa một số Cleartext, thì tôi sẽ lưu trữ khóa ở đâu? Bất cứ điều gì phần mềm có quyền truy cập, kẻ tấn công xác định sẽ có quyền truy cập, bất kể mức độ che giấu nào:

• Nói rằng khóa được bảo vệ bởi mô hình bảo mật của hệ thống tập tin; Nhưng những gì về siêu nhân (độc hại), hoặc nền tảng không cung cấp độ trung thực như vậy?
• Hoặc khóa được mã hóa cứng thành nhị phân phần mềm, nhưng nó luôn có thể được dịch ngược và phần mềm nguồn mở hoặc mã được giải thích thì sao?
• Nếu khóa được tạo, một thuật toán như vậy sẽ cần phải có tính xác định (có lẽ) và sau đó cùng một vấn đề áp dụng cho hạt giống.
• v.v.

Mật mã chỉ mạnh bằng liên kết yếu nhất trong chuỗi của nó và điều này có vẻ như là một liên kết khá lỏng lẻo! Giả sử đó là công cụ phù hợp cho công việc (hài hước cho tôi), vậy thì làm thế nào để bảo mật thông tin đó một cách mạnh mẽ?

Về công cụ phù hợp cho công việc: Có thể, ví dụ - trong trường hợp truy cập dịch vụ (DB, máy chủ xác thực, v.v.), bạn sẽ hạn chế quyền truy cập ở tầng này với tài khoản dịch vụ, có thể với một số cấp độ dịch vụ kiểm toán, v.v. và vì vậy việc có các thông tin trong Cleartext không phải là một vấn đề đáng lo ngại.

Tuy nhiên, với tôi điều đó dường như vẫn chưa thỏa đáng: tôi không muốn ai chọc vào nơi họ không nên đến!

Trước hết, tôi sẽ không đề cập đến bản thân mình như một chuyên gia bảo mật, nhưng tôi đã ở vào vị trí phải trả lời câu hỏi này. Điều tôi phát hiện ra làm tôi ngạc nhiên một chút: Không có thứ gọi là hệ thống hoàn toàn an toàn . Chà, tôi đoán một hệ thống hoàn toàn an toàn sẽ là một hệ thống mà tất cả các máy chủ đều bị tắt :)

Một người làm việc với tôi tại thời điểm đó đã mô tả việc thiết kế một hệ thống an toàn về mặt nâng thanh cho những kẻ xâm nhập. Vì vậy, mỗi lớp bảo mật làm giảm cơ hội cho một cuộc tấn công.

Ví dụ, ngay cả khi bạn có thể bảo mật hoàn toàn khóa riêng, hệ thống không hoàn toàn an toàn. Nhưng, sử dụng chính xác các thuật toán bảo mật và được cập nhật với các bản vá làm tăng thanh. Nhưng, vâng, một siêu máy tính đủ mạnh và có đủ thời gian có thể phá vỡ mã hóa. Tôi chắc chắn tất cả những điều này đã được hiểu, vì vậy tôi sẽ nhận lại câu hỏi.

Câu hỏi rất rõ ràng nên trước tiên tôi sẽ cố gắng giải quyết từng điểm của bạn:

Nói rằng khóa được bảo vệ bởi mô hình bảo mật của hệ thống tập tin; Nhưng những gì về siêu nhân (độc hại), hoặc nền tảng không cung cấp độ trung thực như vậy?

Có, nếu bạn sử dụng một cái gì đó như Windows Key Store hoặc mật khẩu TLS được mã hóa mật khẩu, bạn sẽ tiếp xúc với người dùng có mật khẩu (hoặc quyền truy cập) vào các khóa riêng. Nhưng, tôi nghĩ rằng bạn sẽ đồng ý rằng tăng thanh. Các ACL hệ thống tệp (nếu được triển khai đúng cách) cung cấp mức độ bảo vệ khá tốt. Và bạn đang ở vị trí để cá nhân bác sĩ thú y và biết siêu người dùng của bạn.

Hoặc khóa được mã hóa cứng thành nhị phân phần mềm, nhưng nó luôn có thể được dịch ngược và phần mềm nguồn mở hoặc mã được giải thích thì sao?

Có, tôi đã thấy các khóa mã hóa cứng trong nhị phân. Một lần nữa, điều này làm tăng thanh một chút. Ai đó tấn công hệ thống này (nếu là Java) phải hiểu rằng Java tạo mã byte (v.v.) và phải hiểu cách dịch ngược nó đang đọc nó. Nếu bạn đang sử dụng ngôn ngữ ghi trực tiếp vào mã máy, bạn có thể thấy rằng ngôn ngữ này sẽ tăng thanh cao hơn một chút. Nó không phải là một giải pháp bảo mật lý tưởng, nhưng có thể cung cấp một số mức độ bảo vệ.

Nếu khóa được tạo, một thuật toán như vậy sẽ cần phải có tính xác định (có lẽ) và sau đó cùng một vấn đề áp dụng cho hạt giống.

Có, về cơ bản, thuật toán trở thành thông tin khóa riêng để tạo khóa riêng. Vì vậy, nó sẽ cần phải được bảo vệ.

Vì vậy, tôi nghĩ rằng bạn đã xác định được một vấn đề cốt lõi với bất kỳ chính sách bảo mật, quản lý khóa nào . Có một chính sách quản lý quan trọng tại chỗ là trung tâm để cung cấp một hệ thống an toàn. Và, nó là một chủ đề khá rộng .

Vì vậy, câu hỏi là, hệ thống của bạn (và, do đó, khóa riêng) cần phải an toàn đến mức nào? Làm thế nào cao, trong hệ thống của bạn, thanh cần phải được nâng lên?

Bây giờ, nếu bạn sẵn sàng trả tiền, có một số người tạo ra giải pháp cho việc này. Chúng tôi đã kết thúc bằng cách sử dụng một HSM (Module bảo mật phần cứng) . Nó về cơ bản là một máy chủ chống giả mạo có chứa một khóa trong phần cứng. Khóa này sau đó có thể được sử dụng để tạo các khóa khác được sử dụng để mã hóa. Ý tưởng ở đây là (nếu được cấu hình đúng), khóa không bao giờ rời khỏi HSM. HSM chi phí rất nhiều . Nhưng ở một số doanh nghiệp (bảo vệ dữ liệu thẻ tín dụng cho biết), chi phí vi phạm cao hơn nhiều. Vì vậy, có một sự cân bằng.

Nhiều HSM sử dụng thẻ chính từ bảo trì và quản trị các tính năng. Một đại biểu gồm các thẻ khóa (5 trên 9 cho biết) phải được đưa vào máy chủ để thay đổi khóa. Vì vậy, điều này làm tăng thanh khá cao bằng cách chỉ cho phép vi phạm nếu một đại biểu siêu người dùng thông đồng.

Có thể có các giải pháp phần mềm ngoài đó cung cấp các tính năng tương tự như HSM nhưng tôi không biết chúng là gì.

Tôi biết điều này chỉ đi một số cách để trả lời câu hỏi, nhưng tôi hy vọng điều này sẽ giúp.

Những gì bạn muốn không thể được thực hiện.

Nói rằng khóa được bảo vệ bởi mô hình bảo mật của hệ thống tập tin; Nhưng những gì về siêu nhân (độc hại), hoặc nền tảng không cung cấp độ trung thực như vậy?

Về cơ bản bạn muốn bảo vệ khỏi những người biến thành độc hại. Trong mô hình của bạn, tại một số điểm, ai đó sẽ có quyền truy cập vào khóa. Nếu người đó độc hại thì sao? Nếu bạn độc hại thì sao? Hãy xem, vấn đề như bạn nêu là không thể giải quyết được ngoại trừ việc không có chìa khóa nào cả.

Vì vậy, không làm việc với thông tin cơ sở dữ liệu nhưng các cơ chế xác thực khác. Nhưng không có vấn đề gì, một số người cần có quyền truy cập vào dữ liệu và ai đó có thể độc hại.

Đây là một trong những vấn đề không thể thực sự được giải quyết ở cùng mức độ mà nó đã được tạo ra. Chúng ta sẽ phải lùi một bước về một số triết lý cơ bản, và đi theo dòng thác với hy vọng giải quyết.

Triết lý đầu tiên là "không bao giờ tin tưởng khách hàng" và liên quan chặt chẽ "nếu bạn thực sự muốn giữ bí mật, đừng nói với ai!"

Một ví dụ đơn giản là thông tin cơ sở dữ liệu, như bạn đã đề cập. Rõ ràng bạn muốn khách hàng của mình có quyền truy cập vào nó, nhưng không phải bất kỳ Người lạ Internet ngẫu nhiên nào, vì vậy bạn cần một số loại hệ thống nhận dạng / xác minh / đăng nhập. Nhưng tiền đề cốt lõi của việc che giấu điều này là một vấn đề: nếu chính người dùng phải sở hữu một bí mật, nhưng bạn không muốn họ biết bí mật đó là gì, tất cả những gì bạn có thể làm là che giấu nó hoặc khiến họ khó mở " gói bí mật ". Nhưng họ vẫn có thể tìm ra, vì vậy tốt hơn là bạn nên có một kế hoạch dự phòng!

Giải pháp đơn giản nhất là "đừng làm vậy." Sử dụng thông tin đăng nhập tài khoản của người dùng để cho phép truy cập cơ sở dữ liệu của khách hàng vào phần mềm và đó là thông tin đó. Nếu máy khách trở nên độc hại, trường hợp xấu nhất là máy khách có thể làm hỏng dữ liệu của chính họ. Đó là nó. Cơ sở dữ liệu và hệ thống của bạn, tối đa, hiện chứa các mục rác từ ứng dụng khách đó, chỉ dành cho khách hàng đó, không có ai khác (bao gồm cả bạn) phải chịu đựng tình trạng hỗn loạn.

Có những trường hợp sử dụng cụ thể mà bạn chỉ muốn phần mềm được triển khai để làm một cái gì đó nhưng không phải tất cả mọi người trên thế giới đều có thể kết nối và làm những thứ tương tự, nhưng vì bạn chỉ che giấu bí mật và lý do chính đáng duy nhất để làm điều đó chỉ là giảm đau đầu hoặc hoạt động hệ thống. Nếu thông tin ẩn của bạn trở thành kiến ​​thức phổ biến thì tốt nhất không nên phá game, chỉ gây khó chịu nhất.

Nếu bạn đang ở trong một trong những trường hợp sử dụng hẹp đó, thì đó chỉ là về sự xáo trộn, tất cả là về việc sáng tạo. Thật sự rất giống Code Golf, thực sự - ngoại trừ bạn là người tạo ra câu đố. Đó là tất cả những gì nó thực sự là - một câu đố. Và mọi người thích giải câu đố, vì vậy một lần nữa, tốt hơn hết là nên có người nhận ra.

Nhưng đối với phần lớn mọi thứ trên thế giới, tốt nhất là vận hành mà không phải lo lắng về việc phải giữ bí mật với người dùng. Thay vào đó, cách tốt nhất là chỉ cho người dùng vào bí mật, đặt trách nhiệm của họ là giúp bảo vệ nó (ví dụ như tên người dùng và mật khẩu của họ) và hạn chế rủi ro bất lợi về những gì xảy ra nếu bí mật bị lộ hoặc bị lạm dụng.

Trong bối cảnh mật mã / bảo mật "quản lý khóa" thực sự, câu trả lời của "nơi lưu trữ khóa riêng" là "ở một nơi khác!" Mã hóa là bảo vệ điểm-điểm và mã hóa khóa công khai được thiết kế để bảo vệ thông tin trong quá trình xuyên thời gian và không gian. Khóa riêng vốn đã dễ bị tổn thương và việc bảo vệ nó không thực sự là một câu hỏi về mã hóa chồng chéo - nó đang bảo vệ nó chống lại quyền truy cập hoàn toàn. Và nếu Hệ thống phải truy cập vào nó, thì Hệ thống phải được bảo mật - và bạn không thể làm điều đó trên máy của khách hàng. Họ luôn có thể chạy VM, kết xuất RAM, đánh hơi lưu lượng mạng, cài đặt proxy hoặc ảo ảo, dịch ngược các tệp thực thi ... không tự nguyện tham gia vào trận chiến thua đó.

Bây giờ nếu bạn cần làm một cái gì đó như DRM, nơi bạn cần lưu trữ bí mật thực sự dựa trên việc kiểm soát việc sử dụng phần mềm, thì đó hoàn toàn là một tình huống khác .

TLDR: Đừng giữ bí mật TỪ người dùng, hãy giữ bí mật với người dùng.

Một trong những hệ thống tôi hiện đang sử dụng hoạt động theo cách này.

• Tôi bắt đầu với một hình thức đăng nhập của dịch vụ xác thực. Nó sử dụng xác thực hai yếu tố để đảm bảo tôi là chính mình.
• Tôi nhận được chứng chỉ SSL tạm thời mà tôi có thể sử dụng để truy cập dịch vụ được bảo vệ. Dịch vụ theo dõi các chứng chỉ mà nó chấp nhận.
• Trao đổi của tôi được mã hóa bởi chứng chỉ này từ nghe lén. Cố gắng để crack nó không phải là rất hữu ích vì nó sẽ hết hạn.
• Chứng chỉ hết hạn nhanh chóng (trong vài giờ), nhưng không quá nhanh để tôi không cần cung cấp mật khẩu cho mỗi tương tác.
• Giấy chứng nhận có thể bị thu hồi ngay lập tức ở phía bên kia.

Tất nhiên dịch vụ được bảo vệ chạy ở đâu đó ngoài tầm với của tôi. Nó có thể chạy trên máy của tôi dưới một tài khoản khác (và có thể trong một container), nhưng tôi có các đặc quyền siêu người dùng và sau đó có thể cố gắng tránh các hạn chế.

Về cơ bản nếu bạn có một siêu người dùng độc hại, tất cả các cược đã tắt. Và bạn nên thừa nhận sự hiện diện của một siêu người dùng độc hại trong mô hình mối đe dọa của bạn.

Vì vậy, bạn cần cách ly dịch vụ được bảo vệ của bạn khỏi máy có thể truy cập của khách hàng. Di chuyển dịch vụ được bảo vệ sang một máy chỉ có thể truy cập qua mạng. Đặt khách hàng của bạn vào các máy ảo ngăn không cho chúng tiếp cận với phần còn lại của máy vật lý nơi dịch vụ được bảo vệ của bạn chạy.

Nếu dịch vụ được bảo vệ của bạn không quá quý giá để có thể ra lệnh cho các biện pháp đó, hãy sử dụng bất kỳ khóa mã hóa nào mà HĐH cung cấp cho bạn: cả Windows, Linux và OSX đều có triển khai khóa.

Trong tâm trí của tôi, cách duy nhất để giữ an toàn tuyệt đối này là mã hóa khóa / mật khẩu bằng cụm mật khẩu để mở khóa. Bằng cách này, cụm mật khẩu phải được cung cấp cho mỗi lần bắt đầu hoặc sử dụng bí mật .. Không quá hữu ích.

Một cách khác có thể là để hệ thống bảo mật là tài khoản cơ sở dữ liệu tự nó. Không có khả năng mở rộng ...

Nếu mỗi người dùng trên một hệ thống có tài khoản DB riêng và những tài khoản đó đã được xử lý trước để ứng dụng không có quyền tạo tài khoản trong DB thay cho người dùng, bạn có thể đến khá gần. Cũng không phải là một giải pháp tốt, vì vậy tôi đoán bạn phải hạn chế quyền truy cập đọc trên các tệp cấu hình và tin tưởng siêu người dùng của bạn.