5. Kriptografik Nesneler | MLS (RFC 9420)

5.1 Şifre Takımları

Her MLS oturumu, grup anahtarı hesaplamalarında kullanılacak aşağıdaki ilkelleri belirleyen tek bir şifre takımı kullanır:

HPKE parametreleri:
- Bir Anahtar Kapsülleme Mekanizması (Key Encapsulation Mechanism, KEM)
- Bir Anahtar Türetme Fonksiyonu (Key Derivation Function, KDF)
- Bir Authenticated Encryption with Associated Data (AEAD) şifreleme algoritması
Bir hash algoritması
Bir Mesaj Kimlik Doğrulama Kodu (MAC) algoritması
Bir imza algoritması

MLS, açık anahtarlı şifreleme için HPKE kullanır [RFC9180]. Şifre takımının KEM'ine bağlı DeriveKeyPair işlevi, sekizlik dizilerini HPKE anahtar çiftlerine eşler. HPKE'de olduğu gibi MLS de, AEAD şifrelemesinin ayrı bir şifreli metin ve etiket yerine ([RFC5116] ile uyumlu biçimde) tek bir şifreli metin çıktısı ürettiğini varsayar.

Şifre takımları CipherSuite türü ile gösterilir. Şifre takımları Bölüm 17.1'de tanımlanmıştır.

5.1.1 Açık Anahtarlar

HPKE açık anahtarları, biçimi alttaki protokol tarafından tanımlanan opak değerlerdir (daha fazla bilgi için bkz. [RFC9180], Bölüm 4).

opaque HPKEPublicKey<V>;

İmza açık anahtarları da benzer şekilde, biçimi şifre takımının imza düzeni tarafından tanımlanan opak değerler olarak gösterilir.

opaque SignaturePublicKey<V>;

Edwards-curve Digital Signature Algorithm (EdDSA) imza düzenlerini (Ed25519 veya Ed448) kullanan şifre takımlarında açık anahtar, [RFC8032]'de belirtilen biçimdedir.

NIST eğrileriyle (P-256, P-384 veya P-521) Elliptic Curve Digital Signature Algorithm'ı (ECDSA) kullanan şifre takımlarında açık anahtar, [RFC8446]'da tanımlanan kodlanmış UncompressedPointRepresentation struct'ı olarak gösterilir.

5.1.2 İmzalama

Bir grubun şifre takımında belirtilen imza algoritması, grup içindeki mesajların imzalanmasında kullanılması zorunlu olan algoritmadır. Bu algoritma, ağacın yapraklarındaki kimlik bilgilerinde belirtilen imza algoritmasıyla (yeni üyeler eklemek için kullanılan KeyPackage'lardaki yaprak düğüm bilgileri dahil) aynı olmalıdır (MUST).

Bu belgede kullanılan imzalar, [RFC8446]'da belirtildiği şekilde kodlanır. Özellikle ECDSA imzaları DER kodludur ve EdDSA imzaları, [RFC8032]'de belirtildiği üzere R ve S'nin birleştirilmesi olarak tanımlanır.

MLS içinde kullanılan farklı imzaları birbirinden ayırmak için, her imzalı değerin önüne aşağıda gösterildiği şekilde bir etiket eklenir:

SignWithLabel(SignatureKey, Label, Content) =
       Signature.Sign(SignatureKey, SignContent)

VerifyWithLabel(VerificationKey, Label, Content, SignatureValue) =
       Signature.Verify(VerificationKey, SignContent, SignatureValue)

Burada SignContent şu şekilde tanımlanır:

struct {
       opaque label<V>;
       opaque content<V>;
} SignContent;

Alanları ise şu değerlere ayarlanır:

label = "MLS 1.0 " + Label;
content = Content;

Signature.Sign ve Signature.Verify işlevleri imza algoritması tarafından tanımlanır. MLS uzantıları grup üyeleri tarafından atılacak imzalar gerektiriyorsa, farklı bir etiket kullanarak SignWithLabel yapısını yeniden kullanmalıdır. Bu etiketlerde çakışmayı önlemek için Bölüm 17.6'da bir IANA kaydı tanımlanmıştır.

5.1.3 Açık Anahtarlı Şifreleme

İmzalamada olduğu gibi MLS, farklı amaçlarla üretilen şifreli metinler arasındaki karışıklığı önlemek için şifreleme işlemlerine bir etiket ve bağlam ekler. Bu etiket ve bağlamı içeren şifreleme ile şifre çözme işlemleri aşağıdaki gibi yapılır:

EncryptWithLabel(PublicKey, Label, Context, Plaintext) =
     SealBase(PublicKey, EncryptContext, "", Plaintext)

DecryptWithLabel(PrivateKey, Label, Context, KEMOutput, Ciphertext) =
     OpenBase(KEMOutput, PrivateKey, EncryptContext, "", Ciphertext)

Burada EncryptContext şu şekilde tanımlanır:

struct {
     opaque label<V>;
     opaque context<V>;
} EncryptContext;

Alanları ise şu değerlere ayarlanır:

label = "MLS 1.0 " + Label;
context = Context;

SealBase ve OpenBase işlevleri, grubun şifre takımı tarafından belirlenen HPKE algoritmaları kullanılarak, [RFC9180]'in 6.1 bölümünde ("Base" MODE'u ile) tanımlanmıştır. MLS uzantıları HPKE şifreleme işlemleri gerektiriyorsa, farklı bir etiket kullanarak EncryptWithLabel yapısını yeniden kullanmalıdır. Bu etiketlerde çakışmayı önlemek için Bölüm 17.7'de bir IANA kaydı tanımlanmıştır.

5.2 Hash Tabanlı Tanımlayıcılar

Bazı MLS mesajları, başka MLS nesnelerine hash yoluyla başvurur. Örneğin Welcome mesajları, hoş karşılanan üyeler için KeyPackage'lara; Commit'ler ise kapsadıkları Proposal'lara başvurur. Bu tanımlayıcılar aşağıdaki şekilde hesaplanır:

opaque HashReference<V>;

HashReference KeyPackageRef;
HashReference ProposalRef;

MakeKeyPackageRef(value)
     = RefHash("MLS 1.0 KeyPackage Reference", value)

MakeProposalRef(value)
     = RefHash("MLS 1.0 Proposal Reference", value)

RefHash(label, value) = Hash(RefHashInput)

Burada RefHashInput şöyle tanımlanır:

struct {
     opaque label<V>;
     opaque value<V>;
} RefHashInput;

Alanları ise şu değerlere ayarlanır:

label = label;
value = value;

Bir KeyPackageRef için değer girdisi kodlanmış KeyPackage'tır ve kullanılacak KDF'yi KeyPackage'ta belirtilen şifre takımı belirler. Bir ProposalRef için değer girdisi, Proposal'ı taşıyan AuthenticatedContent'dir. Son iki durumda KDF, grubun şifre takımı tarafından belirlenir.

5.3 Kimlik Bilgileri

Bir grubun her üyesi, üyeye ait bir veya daha fazla kimliği sağlayan ve bunları üyenin imza anahtarıyla ilişkilendiren bir kimlik bilgisi sunar. Kimlikler ve imza anahtarı, bir grup için kullanılan Kimlik Doğrulama Hizmeti (Authentication Service, AS) tarafından doğrulanır.

Uygulama düzeyinde hangi tanımlayıcıların kullanılacağına karar vermek uygulamaya bağlıdır. Örneğin bir X509Credential içindeki sertifika, subjectAltName uzantısında birden fazla alan adına veya e-posta adresine tanıklık ediyor olabilir. Bir uygulama bunların tamamını kullanıcıya sunmayı seçebilir ya da "istenen" bir alan adı veya e-posta adresi biliyorsa, istenen tanımlayıcının tanıklık edilenler arasında olup olmadığını denetleyebilir. [RFC6125]'teki terminoloji kullanılırsa, bir kimlik bilgisi "sunulan tanımlayıcılar" sağlar; doğrulanan istemci için varsa bir "referans tanımlayıcı" sağlamak ise uygulamaya kalmıştır.

// Değerler için "MLS Credential Types" IANA kaydına bakınız
uint16 CredentialType;

struct {
       opaque cert_data<V>;
} Certificate;

struct {
       CredentialType credential_type;
       select (Credential.credential_type) {
           case basic:
               opaque identity<V>;

           case x509:
               Certificate certificates<V>;
       };
} Credential;

"basic" kimlik bilgisi, ek bir bilgi içermeyen yalın bir kimlik beyanıdır. Kodlanmış kimliğin biçimi uygulama tarafından tanımlanır.

Bir X.509 kimlik bilgisi için certificates alanındaki her giriş, DER kodlu tek bir X.509 sertifikasını temsil eder. Zincir, ilk giriş (certificates[0]) uç varlık sertifikası olacak şekilde sıralanır. Uç varlık sertifikasının subjectPublicKeyInfo alanında kodlanan açık anahtar, bu kimlik bilgisini içeren LeafNode içindeki signature_key ile aynı olmalıdır (MUST). Bir zincir, destekleyen eşlerin zaten elinde bulundurduğu bilinen yaprak dışı sertifikaların herhangi birini atlayabilir (MAY).

5.3.1 Kimlik Bilgisi Doğrulaması

MLS kullanan uygulama, gruptaki her üye için hangi tanımlayıcıları kabul edilebilir bulduğunu belirtmekten sorumludur. Başka bir deyişle, [RFC6125]'in TLS için tanımladığı modeli izleyerek uygulama, grup üyeleri için bir "referans tanımlayıcı" listesi tutar; kimlik bilgileri ise "sunulan tanımlayıcılar" sağlar. Bir grup üyesi, önce üyenin kimlik bilgisinin bazı sunulan tanımlayıcıları meşru biçimde temsil ettiğinin doğrulanması, ardından da üyeye ait referans tanımlayıcıların bu sunulan tanımlayıcılar tarafından doğrulandığının güvenceye alınması yoluyla doğrulanır.

Bu işlevleri yerine getiren sistem parçaları topluca Kimlik Doğrulama Hizmeti (AS) [MLS-ARCH] olarak adlandırılır. AS, üyenin kimlik bilgisinin sunduğu tanımlayıcıların üyenin LeafNode nesnesindeki signature_key alanıyla doğru biçimde ilişkilendirildiğini ve bu tanımlayıcıların üyeye ait referans tanımlayıcılarla eşleştiğini doğruladığında, üyenin kimlik bilgisinin AS ile doğrulandığı söylenir.

Gruba ne zaman yeni bir kimlik bilgisi dahil edilirse, bu kimlik bilgisi AS ile doğrulanmalıdır (MUST). Özellikle protokolde aşağıdaki olaylar sırasında:

Bir üye, gruba yeni bir üye eklemek için bir Add teklifinde kullanacağı bir KeyPackage aldığında
Bir üye, ister Welcome üzerinden ister harici Commit üzerinden olsun, gruba katılmak için kullanacağı bir GroupInfo nesnesi aldığında
Bir üye, gruba üye ekleyen bir Add teklifi aldığında
Bir üye, LeafNode'u ilgili üyeye ait yeni bir kimlik bilgisi içeren bir Update teklifi aldığında
Bir üye, UpdatePath içindeki LeafNode'u commit eden kişi için yeni bir kimlik bilgisi içeren bir Commit aldığında
Gruba bir external_senders uzantısı eklendiğinde
Var olan bir external_senders uzantısı güncellendiğinde

Bir üyenin kimlik bilgisinin değiştirildiği durumlarda, örneğin yukarıdaki Update ve Commit durumlarında, AS ayrıca yeni kimlik bilgisindeki sunulan tanımlayıcılar kümesinin, uygulamanın ilkesine göre, eski kimlik bilgisindeki sunulan tanımlayıcılar kümesinin geçerli bir ardılı olduğunu da doğrulamalıdır (MUST).

5.3.2 Kimlik Bilgilerinin Süresinin Dolması ve İptali

Bazı kimlik bilgisi düzenlerinde geçerli bir kimlik bilgisi belirli bir zamandan sonra "sona erebilir" ya da geçersiz hale gelebilir. Örneğin her X.509 sertifikasının, sertifikanın artık geçerli olmadığı bir zamanı ifade eden bir notAfter alanı vardır.

Süresi dolmuş kimlik bilgileri, Bölüm 5.3.1'deki doğrulama gerekleri ışığında operasyonel sorunlara yol açabilir. Uygulamalar, bu etkileri hafifletmek için bazı operasyonel uygulamalar ve Kimlik Doğrulama Hizmeti ilkelerine yönelik uyarlamalar kullanabilir.

Genel olarak, yeni katılanların gruptaki süresi dolmuş kimlik bilgilerini reddetmesi gibi operasyonel sorunlardan kaçınmak için, bu tür kimlik bilgilerini kullanan uygulamalar, uygulamada mümkün olduğu ölçüde, grupta kullanımda olan tüm kimlik bilgilerinin her zaman geçerli olmasını sağlamalıdır.

Bir üye, kendi kimlik bilgisinin süresinin dolduğunu (veya yakında dolacağını) fark ederse, bunu geçerli bir kimlik bilgisiyle değiştiren bir Update veya Commit düzenlemelidir. Bu nedenle üyeler, Update veya Commit içindeki kimlik bilgisi geçerliyse, süresi dolmuş kimlik bilgilerine sahip üyeler tarafından düzenlenen Update tekliflerini ve Commit'leri kabul etmelidir (SHOULD).

Benzer şekilde, bir istemci geçmişte bir zamanda gönderilmiş mesajları işliyor olduğunda (örneğin çevrimdışı kaldıktan sonra grupla yeniden eşzamanlanırken), istemci, süresi dolmuş kimlik bilgilerine sahip üyelerin imzalarını kabul etmelidir (SHOULD); çünkü kimlik bilgisi, mesaj gönderildiği sırada geçerli olmuş olabilir.

Bir üye, başka bir üyenin kimlik bilgisinin süresinin dolduğunu fark ederse, o üyeyi çıkaran bir Remove düzenleyebilir. Örneğin bir uygulama, Commit düzenlemeye hazırlanan bir üyenin ağaçta süresi dolmuş kimlik bilgilerini denetlemesini ve Commit'ine bu üyeler için Remove teklifleri eklemesini zorunlu kılabilir. Grup ağacının DS tarafından bilindiği durumlarda, DS de ağaçta süresi dolmuş kimlik bilgilerini izleyebilir ve harici Remove teklifleri düzenleyebilir.

Bazı kimlik bilgisi düzenleri, kimlik bilgilerinin iptal edilmesine de olanak tanır. İptal, daha önce geçerli olan bir kimlik bilgisinin geçersiz hale gelmesi bakımından süre dolumuna benzer. Dolayısıyla yukarıdaki değerlendirmelerin çoğu iptal edilmiş kimlik bilgileri için de geçerlidir. Ancak uygulamalar, iptal edilmiş kimlik bilgilerini farklı ele almak isteyebilir; örneğin süresi dolmuş kimlik bilgilerine sahip üyelere güncelleme için zaman tanırken, iptal edilmiş kimlik bilgilerine sahip üyeleri çıkarabilir.

5.3.3 İstemcileri Benzersiz Biçimde Tanımlama

MLS uygulamaları muhtemelen uygulamalara, diğer istemcilerle ilgili protokol işlemlerini (örneğin istemci çıkarma) talep etmenin bir yolunu sağlayacaktır. Bu tür işlevlerin diğer istemcilere bir tür tanımlayıcı kullanarak atıfta bulunması gerekir. MLS istemcileri, operasyonel özellikleri farklı olan birkaç tür tanımlayıcıya sahiptir.

Protokolün iç işleyişinde, grup üyeleri benzersiz olarak yaprak indisleriyle tanımlanır. Ancak yaprak indisi, üyelere yalnızca belirli bir epoch içinde atıfta bulunmak için geçerlidir. Aynı yaprak indisi daha sonraki bir epoch'ta farklı bir üyeyi temsil edebilir veya hiçbir üyeyi temsil etmeyebilir.

Bir gruptaki istemcilerin sunduğu kimlik bilgileri, istemciler için uygulama düzeyindeki tanımlayıcıların kimliğini doğrular. Ancak bu tanımlayıcılar istemcileri benzersiz biçimde tanımlamayabilir. Örneğin bir kullanıcının bir MLS grubunda bulunan birden fazla cihazı varsa, bu cihazlardaki istemcilerin tümü kullanıcının uygulama katmanı tanımlayıcılarını sunabilir.

Gerekirse uygulamalar, uygulamaya özgü tanımlayıcıları bir LeafNode nesnesinin extensions alanına application_id uzantısıyla ekleyebilir.

opaque application_id<V>;

Ancak uygulamalar, application_id uzantısındaki veriye sanki Kimlik Doğrulama Hizmeti tarafından doğrulanmış gibi güvenmemelidir (MUST NOT) ve sunulan tanımlayıcının benzersiz olmadığı durumları zarif biçimde ele almalıdır (SHOULD).