2013-03-19 7 views
6

Czytałem specyfikację JSON Web Encryption (JWE) z latest draft being 08, ponieważ szukamy wsparcia dla JSON Web Tokens (JWT) w naszym serwerze uwierzytelniania.Sprawdzanie poprawności wystawcy tokena zabezpieczającego zaszyfrowanego za pomocą JSON Web Encryption (JWE)?

Za pomocą asymetrycznej metody szyfrowania definiuje klucz symetryczny (klucz główny treści) zaszyfrowany przy użyciu klucza publicznego odbiorców. Ma to sens, aby tylko odbiorca mógł go odszyfrować, a także upewnić się, że token był dla nich przeznaczony.

Normalnie spodziewam się również zobaczyć coś, co udowodni, kto token jest z, np. podpis utworzony przy użyciu klucza prywatnego wystawcy, który można zweryfikować przy użyciu jego klucza publicznego. Jednak wydaje się, że podpisy pochodzą również z klucza głównego treści lub klucza publicznego odbiorcy, bez wzmianki o kluczu prywatnym emitenta.

Bez tego wydaje mi się - pod warunkiem, że oczekiwany format tokena był znany - każdy, kto ma klucz publiczny odbiorcy (tj. Kogokolwiek), może wygenerować ważny token; nie tylko zaufany serwer uwierzytelniający.

Nie jestem ekspertem od kryptografii (daleko od niej), więc jestem pewna, że ​​czegoś tutaj brakuje. W jaki sposób odbiorca sprawdza, czy asymetrycznie zaszyfrowany token pochodzi od zaufanego wystawcy?

Zważywszy, że JSON Web Podpisy (JWS) Specyfikacja ma określić podpisów, które używają klucza prywatnego Emitenta i mogą być zweryfikowane z ich klucza publicznego, zastanawiam się, czy chodzi o to, że ładunek z tokena JWE powinien być żetonem JWS?

Odpowiedz

4

JWT z pewnością pozwala na zagnieżdżone ładunki. W rzeczywistości istnieje specyfikacja specific reference w specyfikacji, gdzie parametr nagłówka cty (typ zawartości) może być ustawiony na JWT, aby wskazać, że ładunek jest w rzeczywistości kolejnym JWT.

Najprawdopodobniej utworzysz JWE i umieścisz go w JWS, podpisanym swoim kluczem prywatnym. To również wydaje się być wnioskiem (lub przynajmniej jednym rozwiązaniem) z this thread na liście mailingowej JOSE. Jest jeszcze jeden related thread w zmniejszaniu rozmiaru ładunku. Ogólnie rzecz biorąc, ta lista mailingowa jest prawdopodobnie warta uwagi, ponieważ jest to miejsce, w którym przebywają ludzie, którzy śledzą specyfikację.

+1

Fajnie, dzięki za referencje. Po dokładniejszym ponownym zapoznaniu się ze specyfikacją sekcja 10 wydaje się również obejmować to i ma dodatkowe wskazówki: "Podczas składania syntaktycznego, operacje podpisywania i szyfrowania dla gniazd JTT mogą być stosowane w dowolnej kolejności, zwykle nadawcy powinni podpisywać wiadomość i następnie zaszyfruj wynik (w ten sposób zaszyfrując podpis), co zapobiega atakom, w których podpis jest usuwany, pozostawiając tylko zaszyfrowaną wiadomość, a także zapewniając prywatność osobie podpisującej, a ponadto podpisy w postaci zaszyfrowanego tekstu nie są uważane za ważne w wielu jurysdykcjach. " –

+0

Tak, myślę, że to ma sens, ponieważ zaszyfrowana wiadomość sama w sobie jest chroniona za pomocą GCM lub schematu encrypt-then-HMAC. Jest to również przeciwieństwo tego, co Mike Jonessuggested na liście mailingowej. Zawsze znajdzie się miejsce, w którym można się gdzieś wyślizgnąć podczas realizacji tego zadania :). –

+0

Potrzebuję odszyfrować JWE i wyodrębnić zestaw oświadczeń w JAVA. Czy jest jakaś biblioteka, która to robi? – user243655

Powiązane problemy