Padding oracle atağı

Kriptolojide padding oracle atağı kriptografik bir mesaja padding(doldurma) denilen yöntemin uygulanması sonucunda ortaya çıkmaktadır. Padding (cryptography) kriptografide özellikle blok şifrelemelerde değişken uzunluktaki mesajların uzatılarak aynı blok uzunluğuna gelmesi için doldurulmasını sağlamaktadır. Açık anahtarlamalı yapılarda da kullanılmaktadır. Oracle, kriptografide bir testin başarılı olup olmadığını gösteren mekanizmaya denir. Bu mekanizma genellikle karşımıza sunucu olarak çıkmaktadır. Padding oracle atağı da , mesaj bloklarının doldurulmasının doğru olup olmamasına cevap verilmesi özelliğine dayanmaktakdır. Bu atak genellikle blok şifrelemelerde kullanılan CBC (Cipher Block Chanining) moduyla ilişkilendirilir. Ayrıca asimetrik algoritmalarda (örneğin OAEP) padding oracle zafiyeti olabilir.^[1]

Simetrik Şifreleme[değiştir | kaynağı değiştir]

Simetrik kriptografide, padding oracle atağı (oracle attack) CBC mode da şifreleme işlemine uygulanabilir. Sunucunun blok doldurma işleminin doğru olup olmadığı bilgisini sızdırması sonucunda saldırgana şifreleme anahtarını bilmeden sunucunun anahtarını kullanarak, şifreyi çözmesine imkân tanımaktadır. CBC modunun şifre çözme mekanizması aşağıda gösterilmiştir.

CBC Modda Atak Örneği[değiştir | kaynağı değiştir]

Saldırganın elinde üç adet $C_{1},C_{2},C_{3}$ şifreli blok olduğunu ve ikinci bloğun (yani $P_{2}$ ) şifresini çözmek istediğini farzedelim. Saldırgan sadece $C_{3}$ son bloğun PKCS7 doldurma(padding) metodu ile doğru olarak doldurulduğunu (padded) biliyor. PKCS7'de doldurma işlemi, $n$ byte kadar eksik byte varsa oraya 0xn şeklindedir. Aşağıdaki resim doldurma işlemini özetlemektedir.

CBC şifre çözme işlemi yukarıdaki resimde de belirtildiği gibi şu şekilde çalışır $P_{i}=D_{K}(C_{i})\oplus C_{i-1},C_{0}=IV.$ Eğer saldırgan $C_{1}$ in son byte'ını değiştirip, $(IV,C_{1},C_{2})$ 'i sunucuya gönderirse, $P_{1}$ 'in tüm bloğu (avalanche effect) ve $P_{2}$ 'nin son byte'ı ( XORing operasyonundan dolayı) etkilenir.

Bundan sonra sunucu, en son şifresi çözülen blokun (yani $P_{2}$ ) doldurmasının(padding) doğru olup olmadığını döndürür (bu kontrol şifresiz mesaj işlenmeden önce gerçekleştirilir).

$b_{-1}$ , $C_{1}$ 'in son byte'ı olsun. Saldırgan $b_{-1}$ 'i şu şekilde değiştirsin $b_{-1}=b_{-1}\oplus z_{-1}\oplus {\text{0x01}}$ ( $z_{-1}$ , $P_{2}$ 'in tahmin edilen son byte'ı olsun). Eğer $z_{-1}$ doğru bir tahmin ise (yani $P_{2}$ 'nin doğru son byte'ı ise), sunucu doldurma(padding) hatası vermeyecektir. Eğer sunucu doldurma (padding) hatası verirse, saldırgan $z_{-1}$ 'in hatalı olduğunu anlayacaktır. Bu sebepten saldırgan $z_{-1}$ için diğer değerleri deneyecektir. Bu şekilde 255 denemede $z_{-1}$ 'in değeri bulunmuş olacaktır. Sonuç olarak $P_{2}$ 'nin son byte'ı elde edilmiş olur.

Saldırgan $P_{2}$ 'nin son byte'ını elde ettikten sonra son byte'dan bir önceki byte'ı bulmaya çalışacaktır. Bunu da $b_{-1}=b_{-1}\oplus z_{-1}\oplus {\text{0x02}}$ ve $b_{-2}=b_{-2}\oplus z_{-2}\oplus {\text{0x02}}$ şeklinde yapacaktır.

Böylelikle saldırgan tüm bloğu elde edebilecektir.

Farz edelimki 128 bits AES kullanılarak şifrelenmiş bloklar var elimizde. Saldırgan $P_{2}$ 'yi 255⋅16 = 4080 denemede elde edebilecektir. Bu atak birkaç saniye içinde başarıyla gerçekleştirilebilir.

Padding oracle atakları[değiştir | kaynağı değiştir]

Orijinal padding oracle atağı 2002 yılında Serge Vaudenay^[2] tarafından yazılmıştır. 2010 yılında ise atak, JavaServer Faces, Ruby on Rails^[3] ve ASP.NET.^[4]^[5]^[6] gibi web çatılarına uygulanmıştır. 2012 de bazı güçlendirilmiş donanımlarada atak yapılabildiği gösterilmiştir^[7]

Birçok TLS geliştiricisi tarafından bu zafiyet giderilmiş olsa da zaman yan-kanal analizi kullanan Lucy Thirteen Attack olarak bilinen atak 2013 yılında yayınlandı. 2014 başlarında, gerçek hayatta bir tehdit olarak değerlendirilmese de teoride ( bkz: Signal-to-noise ratio) bazı sınıf cihazlarda hala uygulanabilir durumdadır. 2015'te, kriptografik protokollere yapılan ataklar indirgeme (downgrade attacks) atakları örneğin Logjam^[8] ve Export RSA/FREAK^[9] atakları gibi karşımıza çıkmaktadır. Bu atak destekleyen istemcilerin daha düşük seviyeli protokelleri kullandırılması prensibine dayanmaktadır. 2014 sonlarında ortaya çıkan PODDLE^[10] atağı ise hem indirgeme(SSLv3.0) hem de padding oracle atağını kullanarak güvensiz protokol kullanımını sağlayarak transfer edilen şifreli verinin ele geçirilmesini sağlamaktadır.

Kaynakça[değiştir | kaynağı değiştir]

^ Manger, James. A Chosen Ciphertext Attack on RSA Optimal Asymmetric Encryption Padding (OAEP) as Standardized in PKCS #1 v2.0http://archiv.infsec.ethz.ch/education/fs08/secsem/Manger01.pdf 14 Ocak 2013 tarihinde Wayback Machine sitesinde arşivlendi.. Telstra Research Laboratories
^ Şablon:Kaynak conference
^ Şablon:Kaynak conference
^ Şablon:Kaynak conference
^ Dennis Fisher (13 Eylül 2010). "'Padding Oracle' Crypto Attack Affects Millions of ASP.NET Apps". Threat Post. 13 Ekim 2010 tarihinde kaynağından arşivlendi. Erişim tarihi: 9 Nisan 2016.
^ Vlad Azarkhin. “Padding Oracle” ASP.NET Vulnerability Explanationhttp://blogs.microsoft.co.il/blogs/linqed/archive/2010/09/19/padding-oracle-asp-net-vulnerability-explanation.aspx 23 Ekim 2010 tarihinde Wayback Machine sitesinde arşivlendi.
^ Romain Bardou, Riccardo Focardi, Yusuke Kawamoto, Lorenzo Simionato, Graham Steel, Joe-Kai Tsay (2012), "Efficient Padding Oracle Attacks on Cryptographic Hardware" (PDF), 11 Ağustos 2014 tarihinde kaynağından arşivlendi (PDF), erişim tarihi: 9 Nisan 2016
^ Matthew Green, Nadia Heninger, Paul Zimmerman (2015), "Imperfect Forward Secrecy: How Diffie-Hellman Fails in Practice" (PDF), 27 Şubat 2020 tarihinde kaynağından (PDF) arşivlendi, erişim tarihi: 9 Nisan 2016 . For further information see https://www.weakdh.org 22 Aralık 2019 tarihinde Wayback Machine sitesinde arşivlendi..
^ Matthew Green. Attack of the week: FREAK (or 'factoring the NSA for fun and profit'). http://blog.cryptographyengineering.com/2015/03/attack-of-week-freak-or-factoring-nsa.html 23 Haziran 2015 tarihinde Wayback Machine sitesinde arşivlendi.
^ Matthew Green, Attack of the week: POODLEhttp://blog.cryptographyengineering.com/2014/10/attack-of-week-poodle.html 23 Haziran 2015 tarihinde Wayback Machine sitesinde arşivlendi.

[1] Manger, James. A Chosen Ciphertext Attack on RSA Optimal Asymmetric Encryption Padding (OAEP) as Standardized in PKCS #1 v2.0http://archiv.infsec.ethz.ch/education/fs08/secsem/Manger01.pdf 14 Ocak 2013 tarihinde Wayback Machine sitesinde arşivlendi.. Telstra Research Laboratories

[2] Şablon:Kaynak conference

[3] Şablon:Kaynak conference

[4] Şablon:Kaynak conference

[5] Dennis Fisher (13 Eylül 2010). "'Padding Oracle' Crypto Attack Affects Millions of ASP.NET Apps". Threat Post. 13 Ekim 2010 tarihinde kaynağından arşivlendi. Erişim tarihi: 9 Nisan 2016.

[6] Vlad Azarkhin. “Padding Oracle” ASP.NET Vulnerability Explanationhttp://blogs.microsoft.co.il/blogs/linqed/archive/2010/09/19/padding-oracle-asp-net-vulnerability-explanation.aspx 23 Ekim 2010 tarihinde Wayback Machine sitesinde arşivlendi.

[7] Romain Bardou, Riccardo Focardi, Yusuke Kawamoto, Lorenzo Simionato, Graham Steel, Joe-Kai Tsay (2012), "Efficient Padding Oracle Attacks on Cryptographic Hardware" (PDF), 11 Ağustos 2014 tarihinde kaynağından arşivlendi (PDF), erişim tarihi: 9 Nisan 2016

[8] Matthew Green, Nadia Heninger, Paul Zimmerman (2015), "Imperfect Forward Secrecy: How Diffie-Hellman Fails in Practice" (PDF), 27 Şubat 2020 tarihinde kaynağından (PDF) arşivlendi, erişim tarihi: 9 Nisan 2016 . For further information see https://www.weakdh.org 22 Aralık 2019 tarihinde Wayback Machine sitesinde arşivlendi..

[9] Matthew Green. Attack of the week: FREAK (or 'factoring the NSA for fun and profit'). http://blog.cryptographyengineering.com/2015/03/attack-of-week-freak-or-factoring-nsa.html 23 Haziran 2015 tarihinde Wayback Machine sitesinde arşivlendi.

[10] Matthew Green, Attack of the week: POODLEhttp://blog.cryptographyengineering.com/2014/10/attack-of-week-poodle.html 23 Haziran 2015 tarihinde Wayback Machine sitesinde arşivlendi.

[1]

[2]

[3]

[4]

[5]

[6]

[7]

[8]

[9]

[10]