Puncte:2

Derivarea cheii semnăturii AWS v4

drapel ht

Generarea antetului de autorizare cu semnătura AWS v4 implică derivarea cheii de semnare după cum urmează:

https://docs.aws.amazon.com/general/latest/gr/signature-v4-examples.html

static byte[] HmacSHA256(String data, byte[] key) aruncă excepția {
    String algorithm="HmacSHA256";
    Mac mac = Mac.getInstance(algoritm);
    mac.init(noua SecretKeySpec(cheie, algoritm));
    return mac.doFinal(data.getBytes("UTF-8"));
}

octet static[] getSignatureKey(String key, String dateStamp, String regionName, String serviceName) aruncă excepția {
    byte[] kSecret = ("AWS4" + cheie).getBytes ("UTF-8");
    octet[] kDate = HmacSHA256(dateStamp, kSecret);
    byte[] kRegion = HmacSHA256(regionName, kDate);
    byte[] kService = HmacSHA256(serviceName, kRegion);
    octet[] kSigning = HmacSHA256("aws4_request", kService);
    returnează kSemnarea;
}
  1. Care este beneficiul calculării HMAC așa cum se arată mai sus, în mai mulți pași următori, în loc să faceți un singur calcul HmacSHA256 peste intrarea concatenată (dateStamp, regionName și serviceName)?
  2. Care este beneficiul abordării de mai sus în loc de a utiliza HKDF standard?
Puncte:3
drapel cn

Schema eșalonată permite ca fiecare pas să fie efectuat de o entitate diferită.

  1. Un server central stochează cheia principală și nu o comunică nimănui. Acest server central ar trebui să aibă disponibilitate ridicată și securitate ridicată, dar poate avea un randament scăzut. Cheia poate fi stocată într-un modul hardware de securitate.
  2. Primul pas combină cheia cu un număr de versiune a protocolului într-un mod clar („AWS4” + cheie). Acest lucru permite unui upgrade de protocol să folosească aceeași cheie, astfel încât să nu fie necesar să distribuiți chei noi în același timp cu actualizarea protocolului.
  3. Al doilea pas combină cheia cu data (HMAC (Ștampila dată, „AWS4” + cheie); cel protocolul specifică o ștampilă de dată cu o rezoluție de 1 zi). Cheia se schimbă în fiecare zi. Modificările mai rapide necesită un debit mai mare pe serverul central, în timp ce modificările mai lente înseamnă un impact mai mare în cazul în care ceva din lanț este compromis.
  4. În fiecare zi, fiecare server de regiune solicită cheia de regiune a zilei kRegiune = HMAC(numeregiune, HMAC(DataStamp, „AWS4” + cheie)). Serverul central poate autentifica serverul de regiune pentru a se asigura că numai serverul unei anumite regiuni poate obține cheia regiunii.
  5. Fiecare serviciu care utilizează cheia solicită propria sa cheie kService = HMAC(kRegion, serviceName) din regiunea în care rulează. Serverul regional poate autentifica serviciul pentru a se asigura că un serviciu nu învață cheia altui serviciu.
  6. Serviciul își combină cheia cu un scop: kSigning = HMAC(kService, „aws4_request”). Acest lucru permite ca aceeași cheie principală să fie utilizată în scopuri diferite, dacă este necesar.

Avantajul acestei eșalonări este că fiecare participant are acces doar la propriile chei. Este imposibil să găsești cheia principală dată kRegiune, sau pentru a găsi cheia de regiune dată kServiciul, sau pentru a găsi cheia de serviciu dată kSemnarea. Acest lucru minimizează impactul unui compromis: doar participanții din lanț sunt afectați. De exemplu, dacă o încălcare este descoperită în centrul de date american pe 2022-01-05 și jurnalele arată că încălcarea a avut loc pe 2022-01-01, atunci numai semnăturile făcute după 2022-01-01 în regiunea americană sunt suspecte și pot trebuie revocat. Semnăturile făcute în Europa sau înainte de 2022-01-01 sunt încă bune.

Desigur, numai implementările mari vor folosi vreodată această flexibilitate. În majoritatea aplicațiilor, întregul calcul se face în aceeași bucată de software într-o singură funcție. Dar protocolul se extinde la implementări mari care utilizează compartimentarea pentru a atenua impactul încălcărilor.

Combinând intrările toate odată:

drapel us
@automatictester Într-adevăr, acest lucru a fost explicat într-una dintre note-urile de anul acesta re: Invent. Scopul principal este de a delega autentificarea către regiuni/servicii individuale. Fiecare serviciu ar primi o cheie derivată pentru utilizator odată valabilă pentru ziua respectivă, astfel încât serviciul în sine nu are acces la cheia secretă, dar serviciul nu ar trebui să contacteze IAM central pentru fiecare cerere de autentificare.
Puncte:1
drapel us

Deci problema pe care AWS o rezolvă aici este că au un tuplu de valori, și anume serviciul, regiunea și data curentă și ar dori să obțină o cheie secretă diferită care depinde de toate aceste valori.

Ați putea continua și face acest lucru cu un PRF obișnuit, dar apoi vă confruntați cu o problemă: și anume nu doriți să aveți o situație în care valorile proaste ale oricăreia dintre intrările de tuplu produc brusc coliziuni cheie. O greșeală clasică ar fi de ex. fie să folosiți concatenarea directă și dacă nu sunt atenți, ajungeți cu (azi) și (azi) dând aceeași cheie. Evident, coardele în joc au mai multă structură decât exemplul, dar grija de bază ar trebui să fie clară.

Acum, cel mai eficient mod de a rezolva problema de mai sus este să utilizați o funcție de asociere care garanții că nu există două tupluri distincte de intrare să producă aceeași ieșire și, prin urmare, aceeași intrare în PRF. Cu toate acestea, proiectarea unor astfel de funcții este, de asemenea, ușor predispusă la erori.

eu ghici Din acest motiv, AWS a ales să folosească acest lanț complicat de invocări HMAC. Acum nu trebuie să-și facă griji cu privire la funcțiile complicate de asociere și tot ceea ce este necesar este o grămadă de evaluări HMAC care ar trebui să fie posibile în aproape toate limbile/mediile. Faptul că aceasta necesită apoi nu mai puțin de operațiuni HMAC este compensat de faptul că toate intrările la această derivare a cheii sunt oarecum static și puteți stoca cheile în cache timp de aproximativ o zi dacă operațiunile HMAC costă timp de calcul considerabil pentru dvs.

automatictester avatar
drapel ht
Nu este calcularea HMAC o dată peste șirul structurat precum `[dateStamp=...;regionName=...;serviceName=...]` o soluție mai ușoară la această problemă?
drapel us
@automatictester este doar o altă soluție, o decizie de proiectare. Când intrarea „structurată” poate conține orice intrare client (cheie s3, id de rând db,.), atunci aș folosi mai degrabă hash imbricat decât să risc orice conflict potențial.
Gilles 'SO- stop being evil' avatar
drapel cn
@automatictester De ce crezi că ar fi mai ușor? Comparați numărul de linii de cod pentru cele două soluții și observați cum, dacă șirul structurat este ușor de construit, înseamnă că adăugați o bibliotecă mare de formatare a datelor ca dependență.

Postează un răspuns

Majoritatea oamenilor nu înțeleg că a pune multe întrebări deblochează învățarea și îmbunătățește legătura interpersonală. În studiile lui Alison, de exemplu, deși oamenii își puteau aminti cu exactitate câte întrebări au fost puse în conversațiile lor, ei nu au intuit legătura dintre întrebări și apreciere. În patru studii, în care participanții au fost implicați în conversații ei înșiși sau au citit transcrieri ale conversațiilor altora, oamenii au avut tendința să nu realizeze că întrebarea ar influența – sau ar fi influențat – nivelul de prietenie dintre conversatori.