Android IKEv2: kullanıcı sertifikası ile CA farklı işler yapar
Bir alan telefonun kim olduğunu kanıtlar, diğeri hangi ağ geçidine güvenileceğine karar verir. Android'in IKEv2 profili bunları ayrı tutar çünkü el sıkışma da öyle yapar.
Hem kullanıcı sertifikası hem de CA sertifikası isteyen bir Android IKEv2 ekranı aynı şeyi iki kez istiyor gibi görünür. Öyle değildir. IKEv2 her iki tarafı da, her iki yönde de, aynı alışverişin içinde doğrular ve telefon her yönde farklı bir rol oynar: kim olduğunu kanıtlamak ve hangi ağ geçidine inandığına karar vermek zorundadır. Kullanıcı sertifikası ilk soruyu yanıtlar, güvenilen bir CA ikincisini yanıtlar ve hiçbiri diğerinin yerini tutamaz.
Tek alışverişte iki doğrulama yönü
IKEv2 bir denetim kanalını iki aşamada kurar. İlk alışveriş algoritmalar ve anahtarlar üzerinde pazarlık eder; ikincisi, IKE_AUTH, her taraftan bir AUTH yükü ile her tarafın kimliğini taşır. Yük, alışveriş üzerinden hesaplanan bir imza veya MAC'tir ve alıcının zaten güvendiği bir şeye karşı doğrulanır.
Ağ geçidi kimliğini kendi sertifikasıyla kanıtlar ve telefon o sertifikanın zincirini güvenmeye razı olduğu bir köke kadar doğrular, ardından sertifikadaki kimliğin ulaşmayı amaçladığı ağ geçidiyle eşleştiğini kontrol eder. Telefon kimliğini kendi kimlik bilgisiyle kanıtlar ve ağ geçidi bunu istemci sertifikasını veren CA'ya karşı doğrular.
İki alanın arkasındaki mekanizmanın tamamı budur. Kullanıcı sertifikası telefonun kendisi hakkında yaptığı bir beyandır; CA alanı telefonun kime inanacağına dair bir beyandır. Birine sahip olup diğerine sahip olmayan bir profil karşılıklı doğrulamayı tamamlayamaz ve kaç kez yeniden denense de bu değişmez. İki arıza hatta farklı görünür: eksik kullanıcı anahtarı telefonun hiç imza üretmesini engellerken, eksik güven çapası ağ geçidinin sertifikasını kabul etmesini engeller.
| Material | Role | What it cannot do |
|---|---|---|
| User certificate plus its private key | Proves possession of the enrolled client identity | Establish that the gateway is the right one |
| Trusted CA certificate | Validates the gateway chain under the intended identity checks | Prove the client's identity to the gateway |
| Expected gateway identity | Pins which server the phone accepts | Grant that user access to every private resource |
Android profil oluşturucusu ne ister
Google'ın IKEv2 profil oluşturucusu her doğrulama yöntemini tek bir sertifika modu olarak değil ayrı ayrı sunar. Dijital imza yöntemi bir kullanıcı sertifikası, bir özel anahtar ve bir sunucu kök CA'sı alır. Diğer yöntemler bir kullanıcı adı ve parola ya da önceden paylaşılan bir anahtar alır.
O imzayı dikkatle okuyun, çünkü yukarıdaki mekanizmayı kodlar. Kullanıcı adı ve parola yönteminde kullanıcının özel anahtarı için alan yoktur ve PSK yönteminde ağ geçidinin güven çapası için alan yoktur, çünkü bu yöntemler farklı şeyleri kanıtlar. Bir parolayı sertifika alanına yapıştırarak onları karıştırmak, IKE_AUTH'ta başarısız olan ve hiçbirini adlandırmayan bir ileti veren bir profil üretir.
Dijital imza yöntemi için belgelenmiş özel anahtar türü RSA'dır. IPsec veya sertifika etiketli bir menü ECDSA desteği anlamına gelmez ve desteklediği varsayımıyla kurulan bir profil, ağ devreye girmeden önce platform API'sinde başarısız olur.
Yalnızca ortak kullanıcı sertifikası neden yetmez
AUTH yükü, istemcinin özel anahtarıyla yapılan, alışveriş üzerine bir imzadır. Ortak sertifikaya sahip olmak ağ geçidinin bir imzayı kontrol etmesini sağlar; telefona bir yararı yoktur, çünkü imza üretmek için anahtara ihtiyaç duyar. Yalnızca .crt dosyasını içe aktarıp anahtarı geride bırakmak bu arızanın en yaygın biçimidir.
Android'in anahtar altyapısı bunu yansıtır. Bir istemci kimliği seçmek KeyChain üzerinden gider ve bu, yalnızca bir sertifika girdisi değil, ilgili özel anahtara erişim gerektirir. İkisini birlikte kuran bir kayıt paketi veya cihaz yönetimi akışı kullanılabilir bir kimlik elde etmenin normal yoludur; sertifika dosyasını elle kopyalamak genellikle değildir.
Yani profildeki iki öğe bir sertifika demeti ve onun kopyası değildir. Biri platformun imzalayabilmesi gereken bir anahtar çifti, diğeri platformun karşılaştırdığı bir güven çapasıdır. Onları iki ayrı olgu olarak kontrol edin: bu profil imzalayabiliyor mu ve kime güveneceğini biliyor mu?
Güven çapaları telefona değil bir uygulamaya aittir
Kullanıcı deposuna bir kök sertifika kurmak her Android uygulamasının ona güvenmesini sağlamaz: Android 7'den beri bir uygulama ağ güvenliği yapılandırması üzerinden bunu seçmek zorundadır ve o sürümden önce kullanıcı tarafından kurulan CA'lar çok daha geniş kabul ediliyordu. Uygulama güven yapılandırması farklı olabilir ve kendi güven malzemesini yöneten bir VPN istemcisi kullanıcı deposuna hiç bakmayabilir. Aynı CA dosyasının bir istemcide çalışıp diğerinde yok sayılmış görünmesinin nedeni budur.
Bundan iki sahiplik modeli çıkar. Sistem tarafından yönetilen bir VPN profili cihazın sertifika kurulumunu veya yönetici kayıt akışını kullanır ve profil sonra amaçlanan CA'ya başvurur. Uygulama tarafından yönetilen bir VPN kendi güven malzemesini tutar ve kendi belgelenmiş içe aktarımını kullanır; bu, Android ayarları ekranından tamamen ayrı olabilir. Kopuk zinciri onardığınız yer de burasıdır: sistem tarafından yönetilen durumda CA deposunda ve profil seçiminde, uygulama tarafından yönetilen durumda istemcinin kendi içe aktarma ekranında.
Herhangi bir şeyi içe aktarmadan önce hangi modelde olduğunuza karar verin, sonra etkin profilin güven seçimini doğrulayın. Operatörün talimatları ile istemcinin menüsü uyuşmuyorsa o kurulum için istemcinin belgelenmiş davranışı geçerlidir, ancak CA yine de doğrulayabildiğiniz bir kanaldan operatörden gelmelidir. Bir dosyanın adı, onu kimin verdiğinin kanıtı değildir.
Önce modu, sonra dosyaları seçin
Sertifika modu bir istemci anahtar çifti, ağ geçidi tarafında veren CA, ağ geçidi sertifikası için bir güven çapası ve o sertifikanın hangi kimliği taşıması gerektiğine dair bir beklenti gerektirir. Kullanıcı adı ve parola modu istemci anahtar çiftini kimlik bilgileriyle değiştirir ama ağ geçidi güven gereksinimini korur. PSK modu ikisini de paylaşılan bir sırla değiştirir ve güven modelini basitleştirmek yerine değiştirir.
Hangisini seçerseniz seçin, normal doğrulamayı açık tutun. İstemcinin sunduğu doğrulama yapma seçeneği, CA alanının yerine getirmek için var olduğu kontrolü ortadan kaldırır; eksik bir güven çapasını düzeltmez. Aynısı, bağlantı onsuz çalıştığı için herhangi bir sunucu sertifikasını kabul etmek için de geçerlidir.
Sonra doğru yerde doğrulayın: malzemeyi içe aktarın, bir kez bağlanın ve istemcinin bağlantı ayrıntılarında ağ geçidi kimliğinin beklediğiniz kimlik olduğunu ve profilin kullanmayı amaçladığınız doğrulama yöntemini bildirdiğini onaylayın. Yanlış yöntem seçiliyken başarılı bir bağlantı, henüz anlamadığınız bir yapılandırmadır ve operatör bir sonraki sefer bir ilkeyi sıkılaştırdığında başarısız olacaktır.