Günümüz dizüstü bilgisayarlarının hepsinde yerleşik güvenlik belirteci var

(ahelwer.ca)

1 puan yazan GN⁺ 4 시간 전 | 1 yorum | WhatsApp'ta paylaş

Güvenlik belirteçleri, özel anahtarı cihazın dışına çıkarmadan cihaz içinde imza atar ve kullanıcının fiziksel bir eylemini gerektirerek uzaktaki bir saldırganın keyfi imza üretmesini zorlaştırır
SSH kimlik doğrulaması, U2F, parolasız yerel oturum açma, sudo ve git commit imzalamada kullanılabilir; modern dizüstü bilgisayarlar ve akıllı telefonlardaki yerleşik güvenlik donanımı YubiKey’in yerini alabilir
ssh-keygen -t ed25519-sk ile oluşturulan “özel anahtar” dosyası gerçek özel anahtar değil, belirteç içindeki anahtarı işaret eden bir handle’dır; aynı belirteçle başka bir bilgisayarda da aynı SSH anahtar dosyası oluşturulabilir
MacBook’ta secure element SSH anahtarı olarak ayarlanabildi ve Touch ID tabanlı SSH oturum açma mümkün oldu; git commit imzalamada ise dosya yolu yerine ssh-agent ve key:: biçiminde user.signingKey ayarı gerekti
Güvenlik belirteçlerinde kayıp durumunda özel anahtar kurtarılamaz ve tekrarlanan dokunmalara alışmanın kullanılabilirlik riski vardır; Windows dizüstü bilgisayarlarda Windows Hello, SSH anahtarı kullanımını yüz tanıma, parmak izi veya PIN ile onaylayabildi

Güvenlik belirteçlerinin avantajları ve sınırları

Uzaktan saldırıları engelleyen temel yapı
- Güvenlik belirteci, özel anahtar/açık anahtar çiftini cihazın içinde tutan; açık anahtarı kolayca dışarı verebilen ama özel anahtarın cihazın dışına çıkmasına izin vermeyen bir aygıttır
- İmzalanacak veri paketi cihaza gönderildiğinde, cihaz içinde özel anahtarla imzalanır ve genellikle yanıp sönen dokunmatik düğmeye basmak gibi fiziksel bir kullanıcı eylemi gerekir
- Uzak bir saldırgan bilgisayara erişse bile kullanıcı gerçek dünyada eylemde bulunmadıkça güvenlik belirteci keyfi bir imza üretmeyeceği için, ~/.ssh dizininde tam SSH özel anahtar/açık anahtar çiftini dosya olarak tutma yöntemine göre daha iyi görünür
- SoloKeys ve Nitrokeys gibi, FOSS firmware isteyenler için seçenekler de vardır
- Daha üst seviye güvenlik belirteçleri yerleşik parmak izi okuyucu gibi biyometrik doğrulama eklese de, özünde önemli olan özel anahtarın cihaz dışına çıkmamasıdır
Kullanılabilirlikten doğan riskler
- Kullanıcı güvenlik belirteci her yanıp söndüğünde basmaya alışırsa, kötü niyetli isteklere de düşünmeden yanıt verebilir
- Art arda imzalama yapılan işlerde belirtece tekrar tekrar dokunmak gerektiğinde, bir kez daha yanıp sönen isteği gerçekten fark etmek zor olabilir
- Apple ve Microsoft, akıllı telefon doğrulama uygulamalarında her erişim isteğine rastgele bir sayı kodu ekleyip bunu kullanıcıya girdirtme yöntemini kullanır; ancak bu zahmetlidir ve TOTP kullanan Authy veya Google Authenticator uygulamalarına kıyasla güvenlik belirteçlerinin kullanılabilirlik avantajını azaltır
Kayıp ve yedekleme sorunu
- Güvenlik belirteci kaybedilirse ilgili özel anahtar kalıcı olarak yok olur ve yedekleme yolu yoktur
- Birden fazla hesapta kilitli kalma riskinden kaçınmak için güvenlik belirteci alırken en az 2 tane alıp aynı hizmetlere kaydetmek gerekir
- Alternatif olarak BIP 39 gibi, özel anahtarı insanların okuyabileceği kelime listesine çevirip yazmaya dayanan yedekleme/kurtarma yöntemleri vardır
- Özel anahtar güvenli enclave’in dışına çıkabiliyorsa, kullanıcının kelime listesini yanlış bir yere yazmasını sağlamaya yönelik phishing saldırıları da mümkün hale gelir
- Tüm güvenlik belirteçlerini kaybetme olasılığı ciddi bir endişeyse, BIP 39 kelime listesi sisteme erişimi geri kazanmak için son çare olabilir

SSH ve git’te güvenlik belirteci kullanımı

SSH özel anahtarını güvenlik belirtecinde tutmak
- Normalde ssh-keygen çalıştırıldığında tam özel anahtarı içeren bir dosya çifti oluşturulur
- Özel anahtarı güvenlik belirtecinde tutmak için Yubico’nun FIDO/U2F rehberi doğrultusunda libfido2 kurulur ve güvenlik belirteci takılıyken ssh-keygen -t ed25519-sk çalıştırılır
- Bu durumda da bir dosya çifti oluşur, ancak “özel anahtar” dosyası gerçek özel anahtar değil, güvenlik belirteci içindeki özel anahtarı gösteren bir handle’dır
- Aynı güvenlik belirteciyle ssh-keygen -t ed25519-sk yeniden çalıştırılırsa herhangi bir bilgisayarda aynı özel anahtar/açık anahtar dosyaları üretilebilir; böylece SSH erişim yetkisi belirli bir bilgisayardaki belirli bir dosyaya değil, güvenlik belirteciyle birlikte taşınır
git kimlik doğrulama ve commit imzalama
- Güvenlik belirtecine dokunulan durumların yaklaşık %90’ı git kullanımı nedeniyle olur
- Git forge’ları push ve pull işlemleri için SSH kimlik doğrulaması sunar; yukarıda oluşturulan id_ed25519_sk.pub dosyası yüklenirse güvenlik belirteci anahtar çifti kullanılabilir
- git, commit imzalamada da SSH anahtarlarını destekler; GitHub belgelerindeki SSH anahtarıyla imzalama anahtarı ayarlama adımları izlenip ardından git config --global commit.gpgsign true çalıştırılırsa tüm commit’ler otomatik olarak imzalanır
- Git forge’ın commit’i size ait imza olarak tanıması için açık anahtarın yeniden yüklenmesi gerekir; bu alan genellikle SSH kimlik doğrulama alanından ayrıdır
Commit imzalamanın zorlukları
- Uzun bir commit listesini rebase ederken tüm commit’leri yeniden imzalamak gerekir
- Parmak izi okuyuculu YubiKey, onlarca commit’i art arda imzalamak için fazla yüksek bir parmak izi başarısızlık oranına sahip olduğundan kullanım bırakılabilir
- git’in “rebase/amend merkezli” wrapper’ı jujutsu’da, commit’leri yalnızca push anında imzalama yöntemi vardır
Linux’ta yerel oturum açma ve sudo
- Linux sistemlerinde Pluggable Authentication Module(PAM) ile güvenlik belirteci, parolasız yerel oturum açma ve sudo yetki yükseltmede kullanılabilir

MacBook’un secure element’ini SSH anahtarı olarak kullanmak

USB-C porta güvenlik belirtecini sürekli takılı bırakmak, yanlışlıkla düşürme veya çarpma durumunda portu ve belirteci bozabilecek küçük bir kaldıraç gibi dışarı taşmasına neden olur
2020 model M1 MacBook Air’de Arian van Putten’ın rehberi izlenerek yerleşik güvenlik bileşeni SSH anahtarı olarak ayarlandı

sc_auth create-ctk-identity -l ssh -k p-256-ne -t bio
ssh-keygen -w /usr/lib/ssh-keychain.dylib -K -N ""

Bu komut, id_ecdsa_sk_rk özel anahtar/açık anahtar dosya çiftini oluşturur ve bu dosyalar ~/.ssh dizinine taşınır
Burada da özel anahtar dosyası gerçek özel anahtar değil, cihaz içindeki anahtara yönelik bir handle olduğu için açıkça paylaşılıp yapıştırılabilecek biçimdedir
Açık anahtarı homelab sunucusunda authorized key olarak eklemek için şu komut çalıştırılır

ssh-copy-id -i ~/.ssh/id_ecdsa_sk_rk.pub <server nickname>

Sonrasında ~/.ssh/config içine şu ayar eklenir

Host *
  IdentityFile ~/.ssh/id_ecdsa_sk_rk
  SecurityKeyProvider=/usr/lib/ssh-keychain.dylib

ssh <server nickname> çalıştırıldığında macOS girişten önce otomatik olarak parmak izi istemini gösterir ve ardından SSH oturumu normal şekilde açılır

MacBook secure element ile git commit imzalamak

git config --global user.signingKey /Users/ahelwer/.ssh/id_ecdsa_sk_rk ayarlanıp .ssh/allowed_signers dosyası güncellense bile git commit imzalama hemen çalışmaz
git, commit imzalamada başarısız olur ve device not found? benzeri hata verir

error: Signing file /var/folders/l5/5wqvq2l10p96wtdtfr6lvrvw0000gn/T//.git_signing_buffer_tmpc4uQgO
Confirm user presence for key ECDSA-SK SHA256:oQDA2SNYb2MoSQcxJVSmWyAeAWPqMp7rxliBRfi87as
Couldn't sign message: device not found?
Signing /var/folders/l5/5wqvq2l10p96wtdtfr6lvrvw0000gn/T//.git_signing_buffer_tmpc4uQgO failed: device not found?

fatal: failed to write commit object

Çözüm, ~/.ssh dizinindeki dosyayı doğrudan göstermek yerine ssh-agent kullanmaktır
Yukarıdaki rehbere göre şu komutla anahtar çifti ssh-agent’a eklenir

ssh-add -K -S /usr/lib/ssh-keychain.dylib

Ardından user.signingKey için dosya yolu değil, ~/.ssh/id_ecdsa_sk_rk.pub içeriğinin başına key:: eklenmiş anahtarın kendisi ~/.gitconfig içine yazılır

[user]
	name = Andrew Helwer
	signingKey = "key::sk-ecdsa-sha2-nistp256@openssh.com AAAAInNrLWVjZHNhLXNoYTItbmlzdHAyNTZAb3BlbnNzaC5jb20AAAAIbmlzdHAyNTYAAABBBGxFEdnIg6ppz+pQCdd1eisjOV4gxrjMv1Y4SbtdLoSm6CJCgPZ6q7lnNyuQQsdnS4/Tllsc656AQL7BO3OS47cAAAAEc3NoOg== ssh:"

Bu ayardan sonra MacBook’un secure element’indeki anahtarla dosyalar imzalanabildi ve GitLab Pages sitesi push edilebildi

Windows ve Linux’ta deneme sonuçları

Şirketin verdiği Windows dizüstü bilgisayarda da hızlı bir deneme yapıldı

winget install Microsoft.OpenSSH.preview
ssh-keygen -t ecdsa-sk

Bu komut da bir özel anahtar/açık anahtar dosya çifti oluşturdu ve SSH bağlantısında Windows Hello’nun standart oturum açma akışı üzerinden yüz tanıma, parmak izi veya PIN’den biri kabul edildi
Linux’ta ise benzer bir gerçek kullanıcı varlığı doğrulamasının ardından secure element’e bağlı dizüstü bilgisayara erişim olmadığı için demo yapılamadı

1 yorum

GN⁺ 4 시간 전

Lobste.rs görüşleri

Harika bir yazı; sırf bunun mümkün olduğunu göstermesi bile çok faydalı
Ben şahsen bunu çalıştıracak doğru kütüphane sürümünü bulamadım ama 1Password 8'in SSH anahtarlarını güvenli biçimde sakladığını ve aracının biyometrik doğrulamayla anahtar kilidini açmayı desteklediğini öğrendim
Böylece artık sadece parmağımı dokundurarak hem git işleri yapabiliyor hem de SSH hostlarına giriş yapabiliyorum
Kılavuz: https://developer.1password.com/docs/ssh/get-started/
- Bitwarden da benzer destek sunuyor: https://bitwarden.com/help/ssh-agent/
Bu yalnızca Mac'e özel gibi görünüyor
- İş yerinde güncel bir Windows dizüstü kullanabildiğim için OpenSSH'yi şu şekilde Windows Hello ile entegre ettim
```
winget install Microsoft.OpenSSH.preview  
ssh-keygen -t ecdsa-sk  
```
  Sonrasında her şey eskisi gibi çalıştı; bir anahtarla herhangi bir yere SSH bağlantısı kurduğumda standart Windows Hello akışından geçip parmak izi okuyucu, yüz tanıma veya PIN seçeneklerinden birini kullanabildim
  Böyle bir güvenlik unsuruna sahip bir Linux sistemi deneme fırsatım olmadı; Linux iş istasyonumda V1 TPM var ama imzalama işlemlerinin gerçekten yalnızca kullanıcı varlığı doğrulandıktan sonra çalışmasını nasıl garanti ederim, bilmiyorum
  Belki Framework gibi bir Linux dizüstüsüne sahip biri bunu deneyebilir. Hatta Asahi'de bile gerçekten çalışabilir
- Büyük ölçüde öyle. Linux veya Windows'ta TPM2 FIDO emülasyon katmanı olup olmadığını bilmiyorum
Peki sağlanan private key dosyasının içinde tam olarak ne var?
- @wrs benden önce yanıtlamış ama ssh: kısmı, yani uygulama, passkey'deki origin'e karşılık geliyor ve host ya da alan adı başına resident key oluştururken faydalı oluyor
  Örneğin aynı fiziksel Yubikey içinde bile amaçlara göre anahtarları ayırmak için kullanılıyor
  flags, donanımın anahtarı nasıl işlemesi gerektiğini belirtir [1]. Aracı da kendi kısıtlarını ekleyebilir
  Teknik olarak FIDO anahtarına başka blob'lar ya da uzantılar da kaydedilebilir; önceki iş yerimde bunu kimlik doğrulamayla birlikte X.509 açık anahtarı gibi yardımcı kimlik bilgileri aktarmak için kullanmıştım. Oldukça hoş bir yöntem
  [1]
```
#define SSH_SK_USER_PRESENCE_REQD  0x01  
#define SSH_SK_USER_VERIFICATION_REQD  0x04  
#define SSH_SK_FORCE_OPERATION    0x10  
#define SSH_SK_RESIDENT_KEY    0x20  
```
- Claude'a göre ve openssh_key_parser ile doğrulayınca yapı şöyle
  Dış sarmalayıcıda openssh-key-v1\0 sihirli değeri, cipher=none, kdf=none var; yani şifreli değil
  74 baytlık açık anahtar blob'unda sk-ssh-ed25519@openssh.com anahtar türü, 32 baytlık Ed25519 noktası fdcce889…03e7852b ve uygulama ssh: bulunuyor; bu değer SSH ile WebAuthn'ın FIDO kimlik bilgilerini ad alanı bazında ayırıyor
  Özel bölüm 248 bayt ve cipher=none olduğu için düz metin. İçinde checkint1 == checkint2 == 0x46744267 rastgele değeri, tekrarlanan anahtar türü ve açık anahtar, uygulama ssh:, flags: 0x01 yer alıyor
  Bu bayrak USER_PRESENCE_REQUIRED anlamına geliyor; yani dokunma gerekiyor ama PIN/kullanıcı doğrulaması yok ve bu, yerleşik olmayan bir anahtar
  key_handle, authenticatorGetAssertion'a verilen 128 baytlık opak bir kimlik bilgisi ID'si; cihaz bunu içeride çözüp Ed25519 tohumunu geri yüklüyor
  Bunun dışında boş reserved, yorum ahelwer@ah-mbair.local ve dolgu 01 02 03 var
- Bunu bir base64 çözücüsüne koyunca şu çıkıyor
  
  openssh-key-v1��none��none��J��sk-ssh-ed25519@openssh.com�� 盘˪<F$KW+��ssh:��FtBgFtBg��sk-ssh-ed25519@openssh.com�� 盘˪<F$KW+��ssh:��fІpF$D8"&0[X 'L=Ev ')BjM]$}rTv6Z+p9O8ݹ%V* f.|қ.%I{9 .W !D"8N ai*W�y53 ��ahelwer@ah-mbair.local
  Burada anahtar standardının v1 sürümü, sk-ssh-ed25519@openssh.com anahtar türü var; nedense tekrarlanıyor; ayrıca insanlar için okunabilir anahtar adı ahelwer@ah-mbair.local da bulunuyor
  Geri kalanı muhtemelen OpenSSH bayrakları; örneğin PIN veya kullanıcı varlığı doğrulamasının gerekip gerekmediği ve OpenSSH'nin challenge ile birlikte FIDO/U2F API'sine gönderebileceği bir handle GUID'i
  OpenSSH, anahtar türüne, özellikle de sk kısmına bakarak bunun gerçek bir özel anahtar değil, güvenlik unsurunu çağırması gerektiği sonucuna varabiliyor
  Sonra güvenlik unsuruyla iletişim kurmasını sağlayacak dinamik kütüphaneyi nereden yükleyeceğini belirlemek için SecurityKeyProvider ayarına veya SSH_SK_PROVIDER ortam değişkenine bakıyor
Bu yazı sadece SSH'den bahsediyor gibi; bilgisayarımdaki Secure Enclave ya da TPM'i FIDO2 veya U2F anahtarı olarak kullanmanın bir yolu var mı?
- Elbette var ve neredeyse varsayılan ayarlarla çalışması gerekir
  Passkey de her web sitesi için ayrı bir özel anahtar kullanan bu yaklaşımın bir biçimi
Bu durum, donanıma bağlanabilen asimetrik veya HMAC API anahtarları desteğinin neden daha yaygın olmadığını düşündürüyor
WebAuthn, DBSC(Device-Bound Session Credentials) ve OAuth2 DPOP gibi bunu daha da ileri taşıyan spesifikasyonların artması sevindirici

Günümüz dizüstü bilgisayarlarının hepsinde yerleşik güvenlik belirteci var

Güvenlik belirteçlerinin avantajları ve sınırları

Uzaktan saldırıları engelleyen temel yapı

Kullanılabilirlikten doğan riskler

Kayıp ve yedekleme sorunu

SSH ve git’te güvenlik belirteci kullanımı

SSH özel anahtarını güvenlik belirtecinde tutmak

git kimlik doğrulama ve commit imzalama

Commit imzalamanın zorlukları

Linux’ta yerel oturum açma ve sudo

MacBook’un secure element’ini SSH anahtarı olarak kullanmak

MacBook secure element ile git commit imzalamak

Windows ve Linux’ta deneme sonuçları

İlgili okumalar

1 yorum

Lobste.rs görüşleri