Özel anahtar nerede saklanır?


22

Yazılımımın bazı bölümlerinin şifrelenmesini istiyorum. Örneğin, bir veritabanı, vb. İçin kimlik bilgileri Bu değerleri bir yerde saklamam gerekiyor, ancak bunu açık metinle yapmak bir saldırganın yetkisiz erişim elde etmesini kolaylaştıracak.

Ancak, bazı açık metinleri şifrelersem, anahtarı nerede saklarım? Bu yazılımın erişebildiği herhangi bir şey, kararlı bir saldırganın, hangi seviyede gizlilik olursa olsun, erişebileceği her şey:

  • Anahtarın dosya sisteminin güvenlik modeli tarafından korunduğunu söyleyin; peki ya (kötü niyetli) süpervizörler veya böyle bir sadakat sağlamayan platformlar?
  • Veya anahtar, yazılım ikili dosyalarına kodlanmıştır, ancak her zaman ayrıştırılabilir ve açık kaynaklı yazılım veya yorumlanmış kod hakkında ne olabilir?
  • Anahtar üretilirse, böyle bir algoritmanın deterministik olması gerekir (muhtemelen) ve aynı sorun tohum için de geçerlidir.
  • vb.

Kriptografi, zincirindeki en zayıf halka kadar güçlüdür ve bu oldukça gevşek görünüyor! Bunun iş için doğru bir araç olduğunu varsayarak (mizahla), o zaman böyle bir bilgiyi nasıl sağlam bir şekilde güvence altına alabilirsiniz?


İş için doğru araçla ilgili olarak: Muhtemelen, örneğin - örneğin - servis erişimi durumunda (DB'ler, kimlik doğrulama sunucuları vb.), Bu kademede erişimi bir servis hesabıyla, belki de bir servis seviyesiyle sınırlandırırsınız. Denetim, vb. ve kimlik bilgilerinin açık metin içinde olması çok da endişe verici değildir.

Ancak bana göre, bu hala yetersiz görünüyor: Olmaması gereken bir yere alay eden kimseyi istemiyorum!


6
Security.SE'de ilgi çekici olabilecek çeşitli gönderiler bulabilirsiniz . Bazı çerçevelerin ve dillerin bunun için özel destek sunduğunu not edeceğim (örneğin, .net'teki şifreli yapılandırma bölümleri).
Brian

9
maalesef, "kötü niyetli bir süpervizör" e karşı yapabileceğiniz pek bir şey yok. Yazılımınızın anahtarlara erişmesi gerektiğinden, yerine koyabileceğiniz herhangi bir ACL'yi değiştirme / atlama yeteneğine sahip oldukları için herhangi bir süper kullanıcı olacaktır.
DXM

16
Kullanıcıya bir sırrın güvenilmemesinden kaçınmanın kesinlikle güvenli yolu, böyle bir sırrın gerekmemesidir. Yaygın bir çözüm, yazılımı kontrolünüz altındaki bir sunucuda çalıştırmak ve yalnızca kullanıcının kendisini sunucuya doğrulayabildiği korumasız bir ön uç dağıtmak ve ardından sunucudan servisler tüketmektir.
amon

2
Amon'un cevabı bir kullanıcı ile sınırlı değil, herhangi bir müşteri ile sınırlı. DXM ayrıca, sisteminizi kurcalamak isteyen birinden koruyamayacağınız ve enerjiyi harcamasını zorlaştırmak için harcayacağınız bir noktaya işaret ediyor. Bunun yerine, ürün üzerindeki enerjiyi harcarlar, öyle yapmak
Kevin

3
Kötü niyetli müşteriler hakkında yapabileceğiniz en iyi şey, onları db'ye doğrudan erişim sağlamak yerine iyi tanımlanmış bir hizmet API'siyle sınırlandırmaktır. Bunun ötesinde bir şey yapamazsınız, çünkü müşteride bir sır saklayamazsınız.
CodesInChaos,

Yanıtlar:


25

Her şeyden önce kendime bir güvenlik uzmanı olarak bahsetmiyorum, ama bu soruyu cevaplamak zorunda kaldım. Bulduğum şey beni biraz şaşırttı: Tamamen güvenli bir sistem diye bir şey yoktur . Tamamen güvenli bir sistemin sunucuların kapalı olduğu bir sistem olacağını sanıyorum :)

O sırada benimle birlikte çalışan biri çıtayı davetsiz misafirlere yükseltmek için güvenli bir sistem tasarlamayı açıkladı . Böylece, her bir güvenlik katmanı bir saldırı fırsatını azaltır.

Örneğin, özel anahtarı tamamen güvenceye alsanız bile, sistem tamamen güvenli değildir . Ancak, güvenlik algoritmalarını doğru kullanmak ve yamalar ile güncel olmak çıtayı yükseltiyor. Ancak, evet, yeterince güçlü ve yeterince zaman verilen süper bir bilgisayar şifrelemeyi kırabilir. Bütün bunların anlaşıldığından eminim, bu yüzden soruyu geri alacağım.

Soru açıktır, bu nedenle ilk önce puanlarınızın her birini ele almaya çalışacağım:

Anahtarın dosya sisteminin güvenlik modeli tarafından korunduğunu söyleyin; peki ya (kötü niyetli) süpervizörler veya böyle bir sadakat sağlamayan platformlar?

Evet, Windows Anahtar Deposu veya şifreli bir TLS özel anahtarı gibi bir şey kullanıyorsanız , şifreyi (veya erişimi olan) özel anahtarlara sahip olan kullanıcılara maruz kalırsınız. Ancak çıtayı yükselteceği konusunda hemfikir olacaksınız. Dosya sistemi ACL'leri (eğer doğru şekilde uygulanırsa) oldukça iyi bir koruma sağlar. Ve şahsen veteriner kullanma ve süper kullanıcılarınızı tanıma konumundasınız.

Veya anahtar, yazılım ikili dosyalarına kodlanmıştır, ancak her zaman ayrıştırılabilir ve açık kaynaklı yazılım veya yorumlanmış kod hakkında ne olabilir?

Evet, ikili kodlarda kodlanmış anahtarlar gördüm. Yine, bu çıtayı biraz yükseltiyor. Bu sisteme saldıran birisi (eğer Java ise), Java'nın bayt kodu (vb.) Ürettiğini ve onu nasıl okuduğunu çözeceğinizi anlamalıdır. Doğrudan makine koduna yazan bir dil kullanıyorsanız, bunun çıtayı biraz daha yükseğe çıkardığını görebilirsiniz. Bu ideal bir güvenlik çözümü değildir, ancak bir düzeyde koruma sağlayabilir.

Anahtar üretilirse, böyle bir algoritmanın deterministik olması gerekir (muhtemelen) ve aynı sorun tohum için de geçerlidir.

Evet, temelde algoritma özel anahtarı oluşturmak için özel anahtar bilgisi haline gelir. Bu yüzden şimdi korunmaya ihtiyacı var.

Bu yüzden, herhangi bir güvenlik politikası olan kilit yönetim ile ilgili temel bir sorun belirlediğinizi düşünüyorum . Kilit bir yönetim politikasına sahip olmak, güvenli bir sistem sağlamak için çok önemlidir. Ve bu oldukça geniş bir konudur .

Öyleyse, soru şu ki, sisteminizin (ve dolayısıyla özel anahtarın) ne kadar güvenli olması gerekiyor? Sisteminizde, çubuğun kaldırılması gerekiyor mu?

Şimdi, ödemeyi kabul ederseniz, orada buna çözüm üreten bazı insanlar var. Bir HSM (Donanım Güvenlik Modülü) kullanarak sona erdi . Temel olarak donanımda bir anahtar içeren kurcalamaya karşı korumalı bir sunucudur. Bu anahtar daha sonra şifreleme için kullanılan diğer anahtarları oluşturmak için kullanılabilir. Buradaki fikir (doğru yapılandırılmışsa), anahtarın HSM'den asla çıkmamasıdır . HSM'ler çok pahalı . Ancak bazı işletmelerde (kredi kartı verilerinin korunması söylenebilir), ihlalin maliyeti daha yüksektir. Yani, bir denge var.

Birçok HSM, bakım ve özelliklerin yönetiminden gelen anahtar kartları kullanır. Bir anahtarı değiştirmek için bir anahtar kart çekirdeğinin (9 dan 5'inin söyleyebilmesi) fiziksel olarak sunucuya yerleştirilmesi gerekir. Bu yüzden, çıtayı yalnızca bir süper kullanıcı çekirdeği toplanırsa bir ihlal sağlayarak çıtayı oldukça yükseltir.

Bir HSM'ye benzer özellikler sağlayan yazılım çözümleri olabilir ama bunların ne olduğunu bilmiyorum.

Bunun sadece soruyu cevaplamanın bir yolunu olduğunu biliyorum, ama umarım bu yardımcı olur.


2
"Tamamen güvenli bir sistem, sunucuların kapalı olduğu bir sistem olurdu" ve onları açmanın hiçbir yolu yoktur.
StingyJack

2

İstediğin şey yapılamaz.

Anahtarın dosya sisteminin güvenlik modeli tarafından korunduğunu söyleyin; peki ya (kötü niyetli) süpervizörler veya böyle bir sadakat sağlamayan platformlar?

Temel olarak kötü niyetli insanlardan korunmak istiyorsun. Modelinizde bir noktada biri anahtara erişebilecek. Ya o kişi zararlıysa? Ya SİZİN kötüyse? Bakın, belirttiğiniz gibi bir sorun, hiç bir anahtarın olmaması dışında çözülemez.

Bu nedenle, Veritabanı kimlik bilgileriyle değil, diğer kimlik doğrulama mekanizmalarıyla çalışma Ancak, ne olursa olsun, bir noktada birisinin verilere erişmesi ve birinin kötü niyetli olabileceğine ihtiyacı var.


2

Bu, yaratıldığı düzeyde gerçekten çözülemeyen sorunlardan biridir. Birkaç temel felsefeye geri adım atmamız ve bir çözümleme umuduyla bu basamağı izlememiz gerekecek.

İlk felsefe "müşteriye asla güvenme" ve yakından ilgili "eğer gerçekten bir sır tutmak istiyorsanız, kimseye söyleme!"

Basit bir örnek, belirttiğiniz gibi veritabanı kimlik bilgileridir. Açıkçası, müşterinizin erişebilmesini istiyorsunuz, ancak rastgele herhangi bir Internet Stranger'ı istemiyorsunuz, bu yüzden bir tür kimlik / doğrulama / giriş sistemine ihtiyacınız var. Ancak bunu gizlemenin temel önceliği bir sorun: kullanıcının bir sırrı olması gerekiyorsa, ancak bu sırrın ne olduğunu bilmelerini istemiyorsanız, tek yapabileceğiniz gizlemek veya açılmasını zorlaştırmaktır ” gizli paket ". Fakat hala öğrenebilirler, bu yüzden bir yedekleme planınız olsa iyi olur!

En kolay çözüm "bunu yapma" dır. Yazılımın veritabanına istemci düzeyinde erişime izin vermek için kullanıcının kendi hesap kimlik bilgilerini kullanın. Müşteri kötüleşirse, en kötü senaryo, müşterinin kendi verilerini mahvedebilmesi olmalıdır. Bu kadar. Veritabanınız ve sisteminiz, artık o müşteriden, yalnızca o müşteri için önemsiz girişler içermeli, kimsenin (siz dahil) kargaşasından muzdarip olmamalıdır.

Sadece konuşlandırılmış yazılımın bir şey yapmasını istediğiniz, ancak dünyadaki herkesin aynı şeyleri birbirine bağlayıp yapamayacağı belirli kullanım durumları vardır, ancak bunun için sırları saklıyorsunuz ve bunun için tek iyi neden baş ağrısı veya sistem aktivitesini azaltır. Eğer gizli bilginiz genel bir bilgi haline gelirse, en kötüsü sinir bozucuda olsa bile, oyun kırıcı olmamalıdır.

Bu dar kullanım durumlarından birindeyseniz, bu tamamen yaratıcılıktan ibaret olan sadece şaşkınlıkla ilgili. Kod Golf gibi bir şey, gerçekten - bulmacayı oluşturan siz hariç. Hepsi bu kadar - bir bilmece. Ve insanlar bulmaca çözmeyi sever, bu yüzden yine, birileri çözdüğünde sorun olmaz.

Ama dünyadaki şeylerin çoğunluğu için, bu gizli tutmak zorunda endişesi olmadan çalışmasına sadece en iyisidir gelen kullanıcı. Bunun yerine, en iyi uygulama, kullanıcının sırrını gizlemesine izin vermek, onu korumasına yardımcı olma sorumluluğunu üstlenmesi (örneğin, kullanıcı adı ve şifresi) ve sırrın çıkarılması veya kötüye kullanılması durumunda ne olacağı riskini sınırlandırmaktır.

Gerçek "anahtar yönetimi" şifreleme / güvenlik bağlamında, "özel anahtarın nerede saklanacağı" cevabı "başka bir yerde!" Şifreleme, noktadan noktaya korumadır ve genel-özel anahtar şifreleme, zaman ve mekanda geçiş sırasında bilgileri korumak için tasarlanmıştır. Özel anahtar, doğası gereği savunmasızdır ve onu korumak, örtüşen şifrelemeyle ilgili bir sorun değildir - tamamen erişime karşı güvence altına almaktadır. Sistemin erişmesi gerekiyorsa, Sistemin kendisi de güvenceye alınmalıdır - bunu müşterinin makinesinde yapamazsınız. Her zaman bir VM çalıştırabilir, RAM'i atabilir, ağ trafiğini koklayabilir, bir proxy veya sanal NIC kurabilir, çalıştırılabilir kodları derine koyabilir ... gönüllü olarak kaybedilen savaşa karışmazlar.

Şimdi, bir sır saklama ihtiyacınızın aslında yazılımın kullanımını kontrol etmeye dayandığı DRM gibi bir şey yapmanız gerekiyorsa, bu tamamen bir başka durum .


TLDR: Kullanıcıdan sır saklamayın, kullanıcı ile sır saklayın.


1

Şu anda kullandığım sistemlerden biri bu şekilde çalışıyor.

  • Kimlik doğrulama servisinin giriş formu ile başlıyorum. Kim olduğumu iddia ettiğimden emin olmak için iki faktörlü kimlik doğrulaması kullanıyor.
  • Korunan servise erişmek için kullanabileceğim geçici bir SSL sertifikası alıyorum. Servis kabul ettiği sertifikaları takip eder.
  • Borsalarım bu sertifika tarafından gizlice dinlenmeden şifreleniyor. Çatlamaya çalışmak, süresi dolduğundan çok kullanışlı değil.
  • Sertifika hızlı bir şekilde (birkaç saat içinde) sona eriyor, ancak çok hızlı değil, böylece her etkileşim için bir şifre vermem gerekmiyor.
  • Sertifika diğer tarafta anında iptal edilebilir.

Tabi ki korumalı servis erişemeyeceğim bir yerde. Makinemde farklı bir hesap altında (ve muhtemelen bir konteynırda) çalışabilir, ancak süper kullanıcı ayrıcalıklarına sahibim ve sonra kısıtlamaları aşmaya çalışabilirim.

Temel olarak, kötü amaçlı bir kullanıcı kullanıyorsanız, tüm bahisler kapalıdır. Ve gerektiğini Tehdit modelinde kötü niyetli bir süper varlığını varsayar.

Bu nedenle, korumalı servisinizi müşterinin erişebileceği bir makineden yalıtmanız gerekir. Korunan servisi yalnızca ağ üzerinden erişilebilen bir makineye taşıyın. Müşterilerinizi, korumalı servisinizin çalıştığı fiziksel makinenin geri kalanına ulaşmalarını engelleyen sanal makinelere koyun.

Korunan hizmetiniz bu tür önlemleri yönetebilecek kadar değerli değilse, işletim sisteminin size verdiği şifreli anahtar deposuna gidin: Hem Windows, Linux hem de OSX'in anahtar uygulamaları vardır.


-1

Aklımda, bunu tamamen güvende tutmanın tek yolu, kilidini açmak için bir parola ile şifreyi şifrelemek. Bu şekilde parola sırrın her başlangıcında veya kullanımında verilmelidir.

Başka bir yol da güvenlik sisteminin kendisinin oluşturduğu veritabanı hesabı olabilir. Çok ölçeklenebilir değil ...

Bir sistemdeki her kullanıcı kendi DB hesabına sahipse ve bu hesaplar önceden hazırlanmıştır, böylece uygulamanın bir kullanıcı adına DB'de hesap oluşturma hakları yoktur, ancak oldukça yakın olabilirsiniz. İyi bir çözüm de değil, yapılandırma dosyalarında çok sınırlı okuma erişimine sahip olmanız ve süper kullanıcılarınıza güvenmeniz gerektiğini düşünüyorum.

Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.