MLS, [MLS-ARCH]'te tanımlanan bağlamda çalışmak üzere tasarlanmıştır. Özellikle, aşağıdaki hizmetlerin sağlandığını varsayıyoruz:
Grup üyelerinin diğer grup üyeleri tarafından sunulan kimlik bilgilerini doğrulamasını sağlayan bir Kimlik Doğrulama Hizmeti (Authentication Service, AS).
MLS mesajlarını protokol katılımcıları arasında yönlendiren bir Teslimat Hizmeti (Delivery Service, DS).
MLS, güvenilir bir AS, ancak büyük ölçüde güvenilmeyen bir DS varsayar. Bir AS'nin ele geçirilmesinin veya hatalı davranmasının etkisi Bölüm 16.10'da açıklanmıştır. MLS, DS ele geçirilmiş olsa bile grup verisinin gizliliğini ve bütünlüğünü koruyacak şekilde tasarlanmıştır; genel olarak DS'den beklenen tek şey mesajları güvenilir biçimde iletmesidir. Bir DS'nin ele geçirilmesinin veya hatalı davranmasının etkisi Bölüm 16.9'da açıklanmıştır.
MLS'nin temel işlevi, sürekli grup kimlik doğrulamalı anahtar değişimidir (authenticated key exchange, AKE). Diğer kimlik doğrulamalı anahtar değişim protokollerinde olduğu gibi (örneğin TLS), protokol katılımcıları ortak bir gizli değer üzerinde anlaşır ve her katılımcı diğer katılımcıların kimliğini doğrulayabilir. Bu sır daha sonra, MLS çerçeveleme katmanı kullanılarak grubun bir katılımcısından diğer katılımcılara gönderilen mesajları korumak için kullanılabilir ya da başka protokollerde kullanılmak üzere dışa aktarılabilir. MLS, grup AKE sağlar; yani protokolde ikiden fazla katılımcı bulunabilir. Ayrıca sürekli grup AKE sağlar; yani protokoldeki katılımcı kümesi zaman içinde değişebilir.
MLS'nin temel örgütleyici ilkeleri gruplar ve epoch'lardır. Bir grup, belirli bir anda ortak bir gizli değeri paylaşan istemcilerden oluşan mantıksal bir topluluğu temsil eder. Bir grubun geçmişi, doğrusal bir epoch dizisine bölünür. Her epoch'ta doğrulanmış bir üye kümesi, yalnızca o epoch'taki grup üyelerince bilinen bir epoch secret üzerinde uzlaşır. Gruba dahil olan üye kümesi bir epoch'tan sonrakine değişebilir ve MLS, epoch secret'a yalnızca geçerli epoch'taki üyelerin erişebilmesini sağlar. Üyeler, epoch secret'tan mesaj şifreleme, grup üyeliği doğrulaması ve benzeri amaçlar için başka paylaşılan sırlar türetir.
Bir MLS grubunun yaratıcısı, grubun ilk epoch'unu herhangi bir protokol etkileşimi olmaksızın tek taraflı olarak oluşturur. Bundan sonra grup üyeleri, MLS mesajları alışverişi yaparak paylaşılan kriptografik durumlarını bir epoch'tan diğerine ilerletir.
Bir KeyPackage nesnesi, bir istemcinin yeteneklerini tanımlar ve o istemciyi bir gruba eklemek için kullanılabilecek anahtarları sağlar.
Bir Proposal mesajı, örneğin bir üyenin eklenmesi ya da çıkarılması gibi, bir sonraki epoch'ta yapılacak bir değişikliği önerir.
Bir Commit mesajı, grup üyelerine bir teklif kümesini uygulama talimatı vererek yeni bir epoch başlatır.
Bir Welcome mesajı, gruba yeni katılan üyeye, eklendiği ya da kendisini gruba eklemek istediği epoch için durumunu başlatmasına yetecek bilgiyi sağlar.
KeyPackage ve Welcome mesajları, bir grubu başlatmak veya yeni üyeleri tanıtmak için kullanılır; bu nedenle grup üyeleri ile henüz grupta olmayan istemciler arasında alışveriş edilirler. Bir istemci, KeyPackage'ını DS aracılığıyla yayımlar; böylece diğer istemciler onu gruplara ekleyebilir. Bir grup üyesi gruba yeni bir üye eklemek istediğinde, o yeni üyenin KeyPackage'ını kullanarak onu ekler ve yeni üyenin yerel durumunu başlatabileceği bir Welcome mesajı oluşturur.
Proposal ve Commit mesajları, grubun bir üyesinden diğer üyelere gönderilir. MLS, bir grup içinde mesaj göndermek için ortak bir çerçeveleme katmanı sağlar: Bir PublicMessage, şifrelenmemiş Proposal ve Commit mesajları için gönderici kimlik doğrulaması sağlar. Bir PrivateMessage ise hem Proposal/Commit mesajları hem de uygulama verileri için şifreleme ve kimlik doğrulaması sağlar.
3.1 Kriptografik Durum ve Evrimi
MLS'nin merkezindeki kriptografik durum, üç sorumluluk alanına ayrılır:
.- ... -.
| |
| | |
| | | Anahtar Çizelgesi
| V |
| epoch_secret |
. | | | .
|\ Ratchet | | | Gizli /|
| \ Ağacı | | | Ağaç / |
| \ | | | / |
| \ | V | / |
| +--> commit_secret --> epoch_secret --> encryption_secret -->+ |
| / | | | \ |
| / | | | \ |
| / | | | \ |
|/ | V | \|
' | epoch_secret |
| | |
| | |
| V |
| |
'- ... -'
Şekil 1: MLS Grup Evrimine Genel Bakış
Grup üyeliğini temsil eden ve grup üyelerine birbirlerini doğrulama ve grubun alt kümelerine verimli biçimde mesaj şifreleme olanağı veren bir ratchet ağacı. Her epoch'un ayrı bir ratchet ağacı vardır. Bu ağaç, anahtar çizelgesi (key schedule) için başlangıç girdisini sağlar.
Epoch'tan epoch'a ilerlemek için kullanılan anahtar türetme zincirini (init_secret ve epoch_secret başta olmak üzere) tanımlayan bir key schedule; ayrıca çok sayıda başka sırrın da nasıl türetildiğini açıklar (bkz. Tablo 4). Örneğin:
Epoch için gizli ağacı (secret tree) başlatmakta kullanılan bir encryption secret.
Başka protokollerin MLS'yi genel amaçlı bir kimlik doğrulamalı grup anahtar değişim mekanizması olarak kullanmasına olanak veren bir exporter secret.
Üyelerin, örneğin bir alt grup ya da ardıl grup oluştururken gruba üyeliklerini kanıtlamak için kullanabileceği bir resumption secret.
Grup üyelerinin mesajları şifrelemek ve doğrulamak için kullandığı paylaşılan sırları temsil eden, key schedule'dan türetilmiş bir secret tree. Her epoch'un ayrı bir secret tree'si vardır.
Grubun her üyesi, grup durumunun bu bileşenlerine ilişkin kısmi bir görünüm tutar. MLS mesajları, bu görünümleri başlatmak ve grup epoch'lar arasında geçiş yaparken bunları eşzamanlı tutmak için kullanılır.
Her yeni epoch bir Commit mesajıyla başlatılır. Commit, grup üyelerine bir Proposal kümesini uygulayarak ratchet ağacına ilişkin görünümlerini güncellemeleri talimatını verir ve güncellenmiş ratchet ağacını kullanarak gruba taze entropi dağıtır. Bu taze entropi, yalnızca yeni epoch'taki üyelere sağlanır; gruptan çıkarılmış üyelere sağlanmaz. Böylece Commit'ler, epoch secret'ın geçerli epoch'taki üyelere gizli kalması özelliğini korur.
Gruba bir veya daha fazla üye ekleyen her Commit için, buna karşılık gelen bir veya daha fazla Welcome mesajı vardır. Her Welcome mesajı, yeni üyelere key schedule ve ratchet ağacına ilişkin görünümlerini başlatmak için ihtiyaç duydukları bilgiyi sağlar; böylece bu görünümler, o epoch'ta grubun diğer üyelerinin elindeki görünümlerle uyumlu hale gelir.
3.2 Örnek Protokol İşleyişi
Bir grubun yaşam döngüsünde üç temel işlem vardır:
Geçerli bir üye tarafından başlatılan yeni üye ekleme;
Bir üyeyi ağaçta temsil eden anahtarların güncellenmesi; ve
Bir üyenin çıkarılması.
Bu işlemlerin her biri, karşılık gelen türde bir mesaj (Add / Update / Remove) gönderilerek "önerilir". Ancak grubun durumu, gruba taze entropi sağlamak üzere bir Commit mesajı gönderilene kadar değişmez. Bu bölümde her teklifin hemen commit edildiğini gösteriyoruz; ancak daha ileri dağıtım senaryolarında bir uygulama, birden fazla teklifi toplayıp hepsini tek seferde commit etmeyi tercih edebilir. Aşağıdaki gösterimlerde Proposal ve Commit mesajlarını doğrudan gösteriyoruz; oysa gerçekte bunlar PublicMessage veya PrivateMessage nesneleri içinde kapsüllenmiş olarak gönderilir.
Bir grup başlatılmadan önce istemciler, DS tarafından sağlanan bir dizine KeyPackage'larını yayımlar (bkz. Şekil 2).
Teslimat Hizmeti
|
.--------' '--------.
| |
Grup
A B C Dizin Kanal
| | | | |
| KeyPackageA | | | |
+------------------------------------------------->| |
| | | | |
| | KeyPackageB | | |
| +-------------------------------->| |
| | | | |
| | | KeyPackageC | |
| | +--------------->| |
| | | | |
Şekil 2: İstemci A, B ve C KeyPackage'larını dizine yayımlar
Şekil 3, önceden yayımlanmış bu KeyPackage'ların bir grup oluşturmak için nasıl kullanıldığını göstermektedir. İstemci A, B ve C istemcileriyle bir grup kurmak istediğinde önce yalnızca kendisini içeren bir grup durumu başlatır ve B ile C için KeyPackage'ları indirir. Her üye için A, o üyeyi eklemeye yönelik bir Add teklifi ile bir Commit mesajı üretir ve bu iki mesajı gruba yayınlar. İstemci A ayrıca bir Welcome mesajı üretir ve bunu doğrudan yeni üyeye gönderir (bunu gruba göndermeye gerek yoktur). A, Commit mesajını Teslimat Hizmeti'nden geri aldıktan sonra durumunu yeni üyenin eklendiğini yansıtacak şekilde günceller.
A durumu güncelledikten, yeni üye Welcome mesajını işledikten ve grubun diğer üyeleri de Commit'i işledikten sonra, hepsi grup durumunun tutarlı gösterimlerine sahip olacaktır; buna yalnızca grup üyelerince bilinen grup sırrı da dahildir. Yeni üye, gruba gönderilen yeni mesajları okuyabilecek ve yeni mesajlar gönderebilecektir; ancak gruba eklenmeden önce gönderilmiş mesajlara erişemeyecektir.
Grup
A B C Dizin Kanal
| | | | |
| KeyPackageB, KeyPackageC | |
|<-------------------------------------------+ |
| | | | |
| | | | Add(A->AB) |
| | | | Commit(Add) |
+--------------------------------------------------------------->|
| | | | |
| Welcome(B) | | | |
+------------->| | | |
| | | | |
| | | | Add(A->AB) |
| | | | Commit(Add) |
|<---------------------------------------------------------------+
| | | | |
| | | | Add(AB->ABC) |
| | | | Commit(Add) |
+--------------------------------------------------------------->|
| | | | |
| | Welcome(C) | | |
+---------------------------->| | |
| | | | |
| | | | Add(AB->ABC) |
| | | | Commit(Add) |
|<---------------------------------------------------------------+
| |<------------------------------------------------+
| | | | |
Şekil 3: İstemci A, B ve C istemcileriyle bir grup oluşturur
Gruba sonraki üyelerin eklenmesi de aynı şekilde ilerler. Gruptaki herhangi bir üye yeni bir istemci için KeyPackage indirebilir, geçerli grubun durumunu güncellemek için kullanacağı Add ve Commit mesajlarını yayınlayabilir ve yeni istemcinin durumunu başlatıp gruba katılmasını sağlayacak bir Welcome mesajı gönderebilir.
Mesajların ileriye dönük gizliliğini ve ele geçirilme sonrası güvenliğini sağlamak için, her üye kendisini gruba temsil eden anahtarları belirli aralıklarla günceller. Bir üye bunu, bir Commit (gerekirse hiç teklif içermeden) göndererek veya başka bir üye tarafından commit edilen bir Update mesajı göndererek yapar (bkz. Şekil 4). Grubun diğer üyeleri bu mesajları işledikten sonra, grubun sırları, ağacın göndericiye karşılık gelen yaprağındaki sırları ele geçirmiş bir saldırgan için bilinmez hale gelir. Şekil 4'te gösterilen senaryonun sonunda grup, hem A hem de B bakımından ele geçirilme sonrası güvenliğe sahiptir.
Update mesajları, grup etkin olduğu sürece düzenli zaman aralıklarında gönderilmelidir (SHOULD) ve güncelleme yapmayan üyeler eninde sonunda gruptan çıkarılmalıdır (SHOULD). Update'ler arasındaki uygun sürenin ne olduğunu belirlemek uygulamaya bırakılmıştır. Bir Update göndermenin amacı, ele geçirilme penceresini proaktif biçimde sınırlamak olduğundan, uygun sıklık genellikle milisaniyeler değil saatler veya günler ölçeğindedir. Örneğin bir uygulama, bir üye başka bir üyeden herhangi bir mesaj aldıktan sonra bir uygulama mesajı gönderdiği her seferde ya da hiç uygulama mesajı gönderilmiyorsa günlük olarak bir Update gönderebilir.
MLS mimarisi, MLS'nin güvenli bir taşıma katmanı üzerinde çalıştırılmasını tavsiye eder (bkz. [MLS-ARCH], Bölüm 7.1). Bu tür taşıma protokolleri, tipik olarak tıkanıklık kontrolü gibi, MLS kullanan bir uygulamanın aynı ağı paylaşan diğer uygulamalar üzerindeki etkisini yöneten işlevler sağlar. Uygulamalar, özellikle yukarıdaki tavsiyeye uymuyorlarsa (örneğin MLS'yi doğrudan UDP üzerinden gönderiyorlarsa), ağ tıkanıklığı gibi sorunlara yol açacak bir hızda MLS mesajı göndermemeye dikkat etmelidir.
Grup
A B ... Z Dizin Kanal
| | | | |
| | Update(B) | | |
| +------------------------------------------->|
| | | | Update(B) |
|<----------------------------------------------------------+
| |<-------------------------------------------+
| | |<----------------------------+
| | | | |
| Commit(Upd) | | | |
+---------------------------------------------------------->|
| | | | Commit(Upd) |
|<----------------------------------------------------------+
| |<-------------------------------------------+
| | |<----------------------------+
| | | | |
Şekil 4: İstemci B, anahtarını güncellemeyi önerir; istemci A da
bu teklifi commit eder
Üyeler gruptan benzer şekilde çıkarılır; bu durum Şekil 5'te gösterilmektedir. Grubun herhangi bir üyesi bir Remove teklifi ve ardından bir Commit mesajı gönderebilir. Commit mesajı, gruptan çıkarılan üye hariç tüm grup üyelerine yeni entropi sağlar. Bu yeni entropi, yeni epoch'un epoch secret'ına eklenir; böylece çıkarılan üye bunu bilemez. Bunun, herhangi bir üyenin başka üyeleri gerçekten gruptan atmaya yetkili olduğu anlamına gelmediğini unutmayın; gruplar, bu temel mekanizmaların üzerinde erişim denetimi ilkeleri uygulayabilir.
Grup
A B ... Z Dizin Kanal
| | | | |
| | | Remove(B) | |
| | | Commit(Rem) | |
| | +---------------------------->|
| | | | |
| | | | Remove(B) |
| | | | Commit(Rem) |
|<----------------------------------------------------------+
| |<-------------------------------------------+
| | |<----------------------------+
| | | | |
Şekil 5: İstemci Z, istemci B'yi gruptan çıkarır
Bu bölümdeki akışların yalnızca örnek olduğunu unutmayın; uygulamalar mesaj akışlarını başka şekillerde de düzenleyebilir. Örneğin:
Welcome mesajlarının mutlaka doğrudan yeni katılanlara gönderilmesi gerekmez. Yeni katılanlara şifrelenmiş olduklarından, uygulama yalnızca grup için yayın kanalına erişebiliyorsa daha geniş biçimde dağıtılabilirler.
Proposal mesajlarının tüm grup üyelerine hemen gönderilmesi gerekmez. Commit'i üreten kişinin, Commit oluşturmadan önce bunlara erişebilmesi; diğer üyelerin de Commit'i işlemeye başlamadan önce bunlara erişebilmesi gerekir.
Commit'i gönderen kişinin, durumunu ilerletmeden önce kendi Commit'ini geri almayı beklemesi zorunlu değildir. Yalnızca kendi Commit'inin grup tarafından uygulanacak bir sonraki Commit olacağını bilmesi gerekir; örneğin bir orkestrasyon sunucusunun verdiği söz temelinde.
3.3 Harici Katılımlar
Gruba yeni bir üye eklemek için kullanılan Welcome tabanlı akışa ek olarak, yeni bir üyenin "harici Commit" yoluyla katılması da mümkündür. Bu mekanizma, mevcut üyelerin yeni üye için bir KeyPackage'a sahip olmadığı durumlarda kullanılabilir; örneğin mevcut üyelerden izin almadan yeni üyelerin katılabildiği "açık" bir grup söz konusu olduğunda.
Şekil 6, harici katılım için tipik bir mesaj akışını göstermektedir. Yeni bir üyenin gruba bu şekilde katılabilmesi için, grubun bir üyesi (A, B), grup için GroupContext'i ve grubun mevcut üyelerine bir sır şifrelemek için kullanılabilecek bir açık anahtarı içeren bir GroupInfo nesnesi yayımlar. Yeni üye Z gruba katılmak istediğinde bu GroupInfo nesnesini indirir ve bunu, Z'yi gruba ekleyen özel biçimli bir Commit oluşturmak için kullanır (ayrıntılar için bkz. Bölüm 12.4.3.2). Grubun mevcut üyeleri bu harici Commit'i normal bir Commit'e benzer şekilde işler ve artık Z'nin de grup üyesi olduğu yeni bir epoch'a ilerler.
Grup
A B Z Dizin Kanal
| | | | |
| GroupInfo | | | |
+------------------------------------------->| |
| | | GroupInfo | |
| | |<-------------+ |
| | | | |
| | | Commit(ExtZ) | |
| | +---------------------------->|
| | | | Commit(ExtZ) |
|<----------------------------------------------------------+
| |<-------------------------------------------+
| | |<----------------------------+
| | | | |
Şekil 6: İstemci A bir GroupInfo nesnesi yayımlar, istemci Z de
bunu kullanarak gruba katılır
3.4 Epoch'lar Arasındaki İlişkiler
Bir grubun tek, doğrusal bir epoch dizisi vardır. Gruplar ve epoch'lar genel olarak birbirinden bağımsızdır. Ancak bazen epoch'ları, ister aynı grup içinde ister gruplar arasında olsun, kriptografik olarak bağlamak yararlı olabilir. MLS, bir epoch'tan çıkarılan entropinin gelecekteki bir epoch'a enjekte edilmesine olanak tanımak için her epoch'tan bir yeniden başlatma önceden paylaşılmış anahtarı (resumption PSK) türetir. Gruba bir PSK enjekte etmek isteyen bir grup üyesi, enjekte edilecek PSK'yi tanımlayan bir PreSharedKey teklifi düzenler (Bölüm 12.1.4). Bu teklif commit edildiğinde, ilgili PSK Bölüm 8.4'te açıklandığı şekilde key schedule'a dahil edilir.
Epoch'ları bu şekilde bağlamak, yeni epoch'a giren üyelerin ancak ve ancak yeniden başlatma anahtarının çıkarıldığı epoch sırasında grubun üyesiydilerse bir anahtar üzerinde uzlaşmalarını garanti eder.
MLS, yeni bir grubu mevcut bir gruba bağlamak için iki yol destekler; bunlar Şekil 7 ve Şekil 8'de gösterilmektedir. Yeniden başlatma (reinitialization), bir grubu kapatır ve aynı üyelerden oluşan, ancak parametreleri farklı olan yeni bir grup oluşturur. Dallanma (branching) ise, orijinal grubun katılımcılarının bir alt kümesiyle yeni bir grup başlatır (orijinal grup üzerinde hiçbir etkisi olmaksızın). Her iki durumda da yeni grup, eski gruba bir resumption PSK aracılığıyla bağlanır.
epoch_A_[n-1]
|
|
|<-- ReInit
|
V
epoch_A_[n] epoch_B_[0]
. |
. PSK(usage=reinit) |
.....................>|
|
V
epoch_B_[1]
Şekil 7: Bir Grubun Yeniden Başlatılması
epoch_A_[n] epoch_B_[0]
| |
| PSK(usage=branch) |
|....................>|
| |
V V
epoch_A_[n+1] epoch_B_[1]
Şekil 8: Bir Grubun Dallanması
Uygulamalar, epoch'ları başka şekillerde bağlamak için de resumption PSK'leri kullanmayı seçebilir. Örneğin Şekil 9, epoch n'den alınan bir resumption PSK'nin epoch n+k'ya enjekte edildiği bir durumu göstermektedir. Bu, Update veya Commit'ler nedeniyle bu üyelerin anahtarlarında meydana gelen değişikliklerden bağımsız olarak, epoch n+k anındaki grup üyelerinin epoch n anında da grup üyesi olduğunu gösterir.
epoch_A_[n]
|
| PSK(usage=application)
|.....................
| .
| .
... ...
| .
| .
V .
epoch_A_[n+k-1] .
| .
| .
|<....................
|
V
epoch_A_[n+k]
Şekil 9: Daha Eski Bir Epoch'tan Entropinin Yeniden Enjekte Edilmesi