Tekelci bir destekçi olarak donanım doğrulaması
(grapheneos.social)- Apple ve Google, donanım tabanlı doğrulama kullanımını genişleterek daha fazla hizmetin bunu benimsemesini teşvik ediyor ve uzun vadede onaylanmamış donanım ile işletim sistemi rekabetini dışlayan yapıyı güçlendiriyor
- Google Play Integrity API ile Apple App Attest API benzer şekilde çalışıyor; Play Integrity,
strong integritydüzeyinde donanım doğrulaması gerektiriyor ve bunu kademeli olarakdevice integrityiçin de zorunlu kılma yönünde ilerliyor - Apple Privacy Pass, Google’ın iptal edilen Web Environment Integrity girişimi ve
reCAPTCHA Mobile Verification, doğrulama zorunluluğunu web’e taşıyor; iOS veya sertifikalı bir Android cihazı yoksa web hizmetlerine erişim engellenebilir - Play Integrity API, GrapheneOS izin verilen hedeflerden daha güvenli olsa bile onu engelliyor; buna karşılık 10 yıldır güvenlik yaması almamış cihazlara izin veriyor, bu da güvenlik gerekçesinden çok Google Mobile Services lisanslaması ve rekabeti dışlama amacını öne çıkarıyor
- Devlet ve banka hizmetleri App Attest ile Play Integrity kullanımını giderek daha fazla şart koşarken fiilen Apple cihazlarını veya Google sertifikalı Android cihazlarını dayatıyor; bu durum Windows, masaüstü Linux ve FreeBSD gibi ortamlardaki web erişimini de etkileyebilir
Web’e yayılan doğrulama zorunluluğu
- Apple’ın Privacy Pass sistemi, kendi donanımında CAPTCHA geçişine yardımcı olmak için donanım doğrulamasını web’e taşıyor
- O dönemde birçok kişi, Apple donanımı kullanmayanları engelleyecek site sayısının fazla olmayacağı düşüncesiyle bunu zararsız gördü
- Hem Apple hem Google, çok daha geniş kapsamlı donanım doğrulamasını web’e taşıma potansiyeline sahip
- Bankalar ve kamu hizmetleri giderek daha fazla mobil uygulama kullanımını şart koşuyor; uygulama içinde doğrulama kullanarak Apple veya Google’ın onayladığı cihaz ve işletim sistemlerini dayatabilirler
- Apple’ın Privacy Pass’i, Google’ın iptal edilen Web Environment Integrity girişimi ve reCAPTCHA Mobile Verification bu eğilimi web’e taşıyor
- reCAPTCHA Mobile Verification hakkında mevcut haberler, bunun etkisini ve anlamını yeterince ele almıyor
- Bu yaklaşım, belirli durumlarda reCAPTCHA’yı geçmek için sertifikalı bir akıllı telefonla QR kod taranmasını isteyerek Windows, masaüstü Linux, OpenBSD gibi platformlara da donanım doğrulama zorunluluğu getiriyor
- Google, reCAPTCHA üzerindeki kontrolü sayesinde web’in büyük bir bölümünü kullanabilmek için iOS veya sertifikalı Android cihazı zorunlu hale getirebilecek bir konumda
- Google, Android sertifikasyon gerekliliklerini tanımlıyor; buna Google Chrome’un paket olarak sunulmasının zorunlu tutulması gibi koşullar da dahil
- reCAPTCHA Mobile Verification şu anda GrapheneOS üzerindeki sandbox’lanmış Google Play ile çalışıyor, ancak donanım doğrulaması olmayan sistemlerde de bunu kullanmaya başlamanın aracı olarak varlığını sürdürüyor
- Bu şart uygulanırsa iOS veya Android cihazı olmayan kişiler, başka ek koşul olmadan da engellenebilir
Play Integrity ve GrapheneOS’un dışlanması
- Google’ın Play Integrity API sistemi, GrapheneOS izin verilen tüm seçeneklerden çok daha güvenli olsa bile GrapheneOS kullanımını yasaklıyor
- Play Integrity API başka alternatifleri de yasaklıyor; bu sadece AOSP tabanlı işletim sistemlerine özgü bir sorun değil
- FreeBSD tabanlı bir mobil işletim sistemi kullansanız da bu sorundan kaçamazsınız; sadece daha fazla dışlanırsınız
- Play Integrity API, 10 yıldır güvenlik yaması almamış cihazlara bile izin veriyor
device integritydüzeyi spoofing ile aşılabilir, ancak Google bu durum yaygın ölçekte kullanılmaya başlarsa bunu oldukça iyi tespit edip engelleyebilirstrong integritydüzeyini aşmak için TEE veya SE’den sızdırılmış anahtarlar gerekir- Play Integrity API çok güvenli değil ve geçici olarak aşılması özellikle zor da değil
- Yazılım kontrollerini spoof eden çerçeveler var ve donanım doğrulamasını aşmak için sızdırılmış anahtarlar da satın alınabiliyor
- Ancak bu tür aşma yöntemleri giderek zorlaşıyor ve geçerlilik süreleri de giderek kısalıyor
- Play Integrity yararlı bir güvenlik özelliği sunmuyor, ancak rekabeti dışlamada oldukça etkili çalışıyor
- Apple App Attest veya Google Play Integrity gerektiren hizmetler, esas olarak Apple ve Google’ın mobil cihazlarda ikili tekelini korumasına yardımcı oluyor
- Play Integrity’nin daha önemli olmasının nedeni AOSP’nin açık kaynak olması
- GrapheneOS donanım doğrulamasıyla doğrulanabilir; Google’ın Play Integrity içinde GrapheneOS’u yasaklamasının nedeni, Google Mobile Services lisansı almaması ve rekabete aykırı kurallara uymaması
- Bu kurallar, Güney Kore gibi yerlerde zaten yasa dışı kabul edildi
- Hizmetler, keyfi donanım ve işletim sistemi kullanımını yasaklamamalı
- Google 10 yıldır yama almamış cihazlara izin verirken çok daha güvenli bir işletim sistemine izin vermediği için güvenlik gerekçesini savunmak zor
- Bu, GMS lisanslaması üzerinden tekelin zorla sürdürülmesi anlamına geliyor
Devlet, banka hizmetleri ve düzenlemenin rolü
- Devletler, yalnızca kendi hizmetlerinde değil ticari hizmetlerde de Apple App Attest ve Google Play Integrity kullanımını giderek daha fazla zorunlu kılıyor
- AB, dijital ödeme, kimlik doğrulama ve yaş doğrulama gibi alanlarda bu gerekliliklerin uygulanması yönündeki eğilime öncülük ediyor
- Birçok AB devlet uygulaması zaten bu gerekliliklere sahip
- Devletler, Apple ve Google’ın ciddi rekabet karşıtı uygulamalarını durdurmak yerine kendi hizmetleri aracılığıyla rekabetin dışlanmasına doğrudan katılıyor
- İnsanlardan Apple cihazı veya Google sertifikalı Android cihazı istemek güvenlik değil, rekabetin sınırlandırılması anlamına geliyor
- Banka ve kamu hizmetlerine erişim ya da belirli reCAPTCHA’ları geçebilmek için değiştirilmemiş iOS veya Google Mobile Services Android cihazı gerekmeye başlaması yalnızca GrapheneOS’un sorunu değil
- Aynı etki Windows, masaüstü Linux ve FreeBSD için de geçerli
- Bu, Pixel, Android cihazları veya AOSP tabanlı işletim sistemlerine özgü bir sorun değil; masaüstü web erişimini de etkileyebilir
Android doğrulama API’leri ve Unified Attestation
- Android, doğrulanmış boot anahtarı parmak izlerine izin vererek alternatif işletim sistemlerini destekleyen standart bir donanım doğrulama sistemi sunuyor
- Android’in donanım doğrulaması esas olarak Google’ın güven kökü ve uzaktan anahtar sağlama hizmetini kullanıyor, ancak API’nin kendisi alternatif güven köklerini destekliyor
- Android donanım doğrulaması, belirli donanım veya işletim sistemi kullanmayan kullanıcıları dışlamak için kullanılmamalı
- Bununla birlikte, keyfi güven kökleri ve işletim sistemlerine izin verebilmesi hizmetlere daha fazla hedefi kabul etme alanı sağlıyor
- Google gerçekten güvenlik amacı güdüyor olsaydı, aynı sistemi kullanarak Play Integrity içinde GrapheneOS’a izin verebilirdi
- Unified Attestation, çeşitli Avrupalı şirketlerin desteklediği, kullanıcıları keyfi donanım ve yazılımdan benzer şekilde dışlayacak başka bir rekabet karşıtı sistem
- Unified Attestation bir çözüm değil; Android’in çok daha açık donanım doğrulama API’sinden çok daha kötü
- Volla’nın Unified Attestation çözümü, tamamen Android’in donanım doğrulama API’si üzerine inşa edilmiş durumda
- Volla’nın Unified Attestation sistemi, neyin kabul edileceğinin merkezi bir otorite ve hizmetler tarafından kontrol edilmesini sağlamak için var
2 yorum
Google’ı o kadar seviyorum ki keşke beş tane falan olsa 🥰
Hacker News görüşleri
EU Digital Identity Wallet (EUDI), Google veya Apple’ın donanım attestasyonu istemesi nedeniyle fiilen AB’deki tüm dijital kimlikleri bu iki ABD devine bağlamış oluyor
Dijital egemenlikten söz ederken böyle bir karar alınmış oluyor ve sanki çocukları koruma meselesi egemenlikten daha öncelikliymiş gibi görünüyor
https://gitlab.opencode.de/bmi/eudi-wallet/wallet-developmen...
Başta neden böyle bir karar alındığını hiç anlayamıyorum
Teknik bilgisi olmayan sıradan kullanıcılara göre yazılmış bir cevap olduğu çok belliydi
Egemenlikten ve ABD’ye bağımlılıktan kurtulmaktan bu kadar çok söz eden insanlar varken neden daha büyük bir itiraz olmadığını anlamıyorum; bunun sebebi sadece cehalet mi diye düşünmeden edemiyorum
Özellikle gizlilik odaklı kimliklerde bu daha da geçerli ve bu yüzden cihaz attestasyonu önemli hale geliyor
Donanımın kullanıcının anahtarları çıkarmasını engellediğini doğrulayamazsanız, kimlik anahtarının cihaza kilitli olduğunu garanti edemezsiniz
En kötü tarafı da şu: Yeterince kararlı suçlular eninde sonunda bu anahtarları çıkarıp dolandırıcılıkta kullanmanın bir yolunu bulacak ve sonuçta açık kaynak ile açık bilişim yok edilecek
Kimlerden kimlik göstermesinin istenmesi gerektiği ayrı bir mesele ve çoğu yalnızca çevrimiçi senaryoda cevabın “hayır” olduğunu düşünüyorum; ancak finans sektörünün onlarca yıldır güvendiği çözüm zaten mevcut
Onaylı silikon ve yazılım istemeleri bile buradaki en büyük sorun değil
Bunlar sıfır bilgi ispatları ya da kör imzalar kullanmıyor
Bu yüzden cihaz üzerinden her doğrulama yapıldığında, o eylemi cihazla ilişkilendirmek için kullanılabilecek bir ispat paketi bırakılıyor
Araya bir sunucu koyup statik cihaz kimliğiyle tek kullanımlık kimlik alarak gizliliği önemsiyormuş gibi bir yapı kuruyorlar ama bu ara sunucuların ne yaptığını bilmediğimiz için hepsinin kayıt tuttuğunu varsaymak gerekir
Yalnızca uzaktan attestasyon yolu böyle; DRM ID yolu daha da kötü. Anlamlı bir ara katman olmadığı için tüm lisans sunucuları silikona kazınmış statik kimliğe erişebiliyor. Google hesabı yolu ise zaten ortada
Uzaktan attestasyonda kör imza kullanılması gerçekten önerilmişti ama şu anda görünür yerlerde kullanılmıyor: <https://en.wikipedia.org/wiki/Direct_Anonymous_Attestation>
Bunun birkaç olası nedeni var. En bariz olanı, istedikleri zaman gizliliği ihlal edebilmek istemeleri ya da böyle bir yeteneği zorunlu olarak bulundurmakla yükümlü olmaları
Diğer neden ise, belirli bir cihazla doğrulamayı bağdaştıramazsanız suistimali azaltmak için geriye pratikte yalnızca hız sınırlaması kalması ve bunun da onların ölçütlerine göre yeterli olmaması olabilir. Saldırganlar bir cihaz çiftliği kurup her cihazın kötü niyetli aktörlere uzaktan attestasyon sağlayarak saat başına gelir üretmesini mümkün kılabilir
Bir hizmetin anonim kalmasını sağlayıp aynı zamanda hız sınırlaması uygulamayı nasıl başarabileceğinizi bilmiyorum
Eğer bir hizmet iki isteğin aynı özneden gelip gelmediğini sayabiliyorsa, iki hizmet de kendini aynı hizmet gibi gösterip bu iki isteğin aynı özneden gelip gelmediğini anlayabilir ve bunları birbiriyle ilişkilendirebilir
“Sorun donanım attestasyonu değil, sıfır bilgi ispatı kullanılmaması” gibi şeyler söylemek yeni bir davranışı normalleştirmektir
Bunu yapmamalıyız. Sıfır bilgi ispatı kullansınlar ya da en yeni güvenlik tekniğiyle donanım attestasyonu yapsınlar fark etmez; sorun donanım attestasyonunun kendisi
Yaş doğrulamasında da aynı durum geçerli. Sorun yaş doğrulamasının veri sızıntılarına açık olması değil; sorun yaş doğrulamasının kendisi
Uygulama duyurulduğundan beri kabaca böyle bir mimariye sahip olduğundan emindim
Graphene forumlarında da DRM ID’nin sadece korunmakla kalmayıp profiller arasında da aynı kaldığına dair tartışmalar gördüğümü hatırlıyorum
Eğer öyleyse, benimsenmesini sağlayacak havuç ya da sopa ne olabilir
Bu, bu teknolojinin neden “açık” olan herhangi bir şey için sorun haline geldiğini çok iyi gösteren bir başlık
“Kendi ayrı web’imizi kurarız” iddiası, tüm hizmetler Google onaylı veya Apple onaylı mobil cihaz sahipliğini zorunlu kılan bir web’in arkasına geçene kadar ancak işe yarar
Google beni bundan zaten tamamen engelliyor
İstenen şeyi seçmek için karelere tıklıyorum, sonsuz döngüye giriyor; sesli sürümü kullanmaya çalışınca da şüpheli etkinlik olduğu söylenerek tamamen engelleniyorum
Bu yüzden artık tek başıma biniyorum ve bu yıl üyeliğimi de yenilemedim
En son buna benzer bir şey yaşadığımda Facebook belirli etkinliklere katılımın tek yolu haline gelmeye başlamıştı. O zaman da sadece dışlandığımı kabul edip zamanımı ve paramı başka yere harcadım
Zaten birçok işletmeye ya da sosyal buluşmaya ancak Facebook, WhatsApp gibi şeylerin arkasından erişilebiliyordu
Bu gerçekten tuhaf bir siberpunk distopya gibi hissettiriyor. Sanki yalnızca aynı özel posta hizmetine abone olan insanlara mektup ve paket gönderebiliyor ya da yalnızca benim araba markamla karşılıklı lisans anlaşması olan yollarda araç kullanabiliyormuşum gibi
Güvenlik özelliği sağlasa bile, Google veya Apple dışındaki işletim sistemlerini ikinci sınıf vatandaş haline getiren yan etki aynen kalıyor ve asıl sorun da bu
Bankalar veya devletle etkileşimler için gerçekçi olmayabilir ama diğer birçok hizmet için mümkün olabilir gibi geliyor
Yine de bir şeyler inşa etme işi hâlâ gerekli ve maliyet daha az kişiye dağılacağı için, reklam teknolojisi geliştirmeye gerek olmamasının getirdiği daha düşük karmaşıklık avantajı bunu telafi etmeyebilir
Yine de bu bir tür iyi malzeme sorunu olabilir. Donanımda ise iş daha zor olur
Kulağa aptalca bir soru gibi geliyor ama ciddi ciddi soruyorum
1999’da Intel CPU’lara yazılımla okunabilen bir seri numarası koymaya karar verdiğinde çok büyük bir tepki olmuştu ve sonunda bu karardan geri dönüldü
Sonrasında da “güvenlik” ve güvenilir bilişimi zorlayan otoriterler TPM ve ilgili teknolojileri itmeye devam etti; bu da mobil duvarlarla çevrili ekosistemlerin yükselişine katkıda bulundu
Windows 11’in TPM gereksinimi de bu hedefe doğru atılmış bir başka adımdı. Bunun iyi bir şey olduğuna dair burada ve başka yerlerde ne kadar çok propaganda yapıldığını görmek beni şaşırtmıştı
“Güvenlik” gerekçesi ortaya atıldığında çok sayıda insanın her şeye kolayca razı edildiği görülüyor. Umarım bu sayı azalıyordur
Genel amaçlı bilişime karşı savaş sürüyor ve savaşmaya devam etmek zorundayız
Stallman her zamanki gibi haklıydı. “Right to Read”i yeniden okumanın zamanı geldi. Hâlâ yoksa AI ile yapılmış bir kısa film de iyi bir fikir olabilir
“Güvenlik uğruna özgürlüğünden vazgeçenler ikisini de hak etmez”
AI tamamen merkezileşmiş ve tekelci bir araç
Bu başlıkta da görüldüğü gibi, bu sorunlar karşısında itici güç, öfke ve öz örgütlü tepki yerine yalnızca “kimse umursamıyor”, “yapabileceğimiz bir şey yok” türü bir umutsuzluk var
Vazgeçmek kaybetmenin en kesin yoludur
Buradaki yorumlar, sanki iddia attestasyonun kendisinin kötü olduğu yönündeymiş gibi okuyor; ama asıl argüman daha çok Apple ve Google dışındaki sağlayıcıların da açıkça kapsanacağı bir yol olması gerektiği gibi görünüyor
Başlık, Apple ve Google’ın kötü olduğu, bunu tekellerini sağlamlaştırmak için yaptığı ve rakipleri GrapheneOS’un da insanlar adına buna karşı durduğu izlenimini veriyor
Ama son itirazın, kendilerinin de dâhil edilmesi gerektiği olması ve Google’ın Play Integrity API’si tarafından belirsiz nedenlerle reddedildiklerini, bunun da kötü niyetli olduğunu öne sürmeleri, onların da güvenlik değerini kabul ettiğini gösteriyor gibi
Önemli kimlik verileri için uçtan uca imza zinciri doğrulaması gerçekten gerekli. Çünkü AI ile sahte kimlikleri kolayca üretmenin önüne geçmenin tek yolu bu
Patentler ve telif hakları özgün tekel biçimleriydi
Yazılım açık kaynak olmadığı sürece, tanım gereği tekelcidir
HN’de GrapheneOS’u destekleyen daha fazla zengin insan olmamasına şaşırıyorum
Bu konuyu önemseyen varlıklı insanlar ile teknologların Venn diyagramı epey örtüşüyor gibi duruyor; Graphene’in kusurları olsa da bu alanda çok sayıda temel çalışma yapıyor
Uygarlığımızın, modern mikroelektroniği üretildikten sonra değiştirebilmenin bir yoluna acilen ihtiyacı var; en azından iyi donanımlı tamir atölyelerinde bunun mümkün olması gerek
Aslında buna dün bile ihtiyaç vardı
Alternatif olarak, genel amaçlı satılan bilişim cihazlarında CPU veya SoC’nin mask ROM’una herhangi bir tür ilk aşama bootloader konularak sevk edilmesini yasadışı hale getirmemiz gerekir
Yani reset’ten sonra CPU’nun çalıştırdığı ilk komut, CPU paketinin dışında fiziksel olarak bulunan bir depolama biriminden gelmeli
Bkz: https://pluralistic.net/2026/01/01/39c3/
Nispeten basit SoC’ler bile, belgelenmemiş bir boot ROM içinde mimari reset vektörüne ulaşmadan önce reset sürecine yardımcı olmak için oldukça fazla iş yapıyor
Yanlışlıkla silinemeyecek bir boot ROM’a düşük seviyeli DFU rutinleri koymanın da ciddi bir değeri var
SoC silikonu, güç verildiği andan güvenli boot devrine kadar çalıştırılan her komutu kaydedecek şekilde revize edilebilir
Durum sorgulama, taşma olup olmadığını bildirme, imza üretme gibi yardımcı komutlar da eklenirse işletim sistemi kendi attestasyonunu üretirken boot öncesi kurcalamaları örtük biçimde raporlayabilir
Bootloader’a hardcoded anahtar materyali koymayı ve o anahtarla yüklenen kodu doğrulamayı yasadışı kılmak yeterli olur
Google ile Apple’ın, kendileriyle tamamen ilgisiz hizmetlere kimin erişip erişemeyeceğine karar vermesine izin veriliyor olması şaşırtıcı
Google karşıtı görüşleriniz yüzünden Google hizmetlerinden engellenip sonra banka hesabınıza da giriş yapamadığınız bir durumu düşünün
Gerçekten Alphabet’i parçalamak gerekiyor
Konu bu kadar ciddi ise, okunması zor bir başlık yerine tek sayfalık, düzgün kurgulanmış mantıklı bir gerçek yazı çok daha iyi olurdu