JavaCard - czysto programowa implementacja ECC ponad GF (2^n)

Mam karty inteligentne od NXP, które obsługują ECC ponad GF (p) i które nie obsługują ECC ponad GF (2^n).JavaCard - czysto programowa implementacja ECC ponad GF (2^n)

W moim projekcie muszę użyć tego konkretnego typu karty inteligentnej (tysiące instancji są już używane). Jednak muszę dodać weryfikację podpisu WE nad sect193r1, który jest krzywa ponad GF (2^n).

Wydajność nie jest dla mnie problemem. To może trochę potrwać. Weryfikacja podpisu nie obejmuje żadnych kluczy prywatnych, więc bezpieczeństwo i zarządzanie kluczami również nie są problemami. Niestety, muszę zweryfikować podpis w mojej karcie inteligentnej, a nie w urządzeniu wyposażonym w czytnik kart inteligentnych.

Czy istnieje rozwiązanie? Czy istnieje jakiś kod źródłowy czystej oprogramowania JavaCard implementacji kryptografii EC nad GF (2^n)?

Źródło

2015-02-12 vojta

Najpierw sprawdziłbym, czy obie implementacje oprogramowania JCRE i Reader obsługują nieograniczoną liczbę oczekujących rozszerzeń w warstwie protokołu 7816/14443, ponieważ zajmie to prawie na zawsze. Zgaduję, że –

@PaulBastian Większość implementacji I zobacz, czy masz dobre wsparcie WTX w dzisiejszych czasach, ale zgadzam się, że nie ma znaczenia, czy po prostu nigdy nie wróci :) –

@MaartenBodewes OK, to brzmi bardzo źle: -) ... Przez "wydajność nie jest problemem" Miałem na myśli coś np. "3 sekundy są OK". Cóż, to wydaje się być przegraną bitwą. Dzięki za wszystkie odpowiedzi! – vojta

Karty inteligentne, które mogą wykonywać kryptografię asymetryczną, zawsze robią to za pomocą współprocesora (zwykle zawierającego mnożnik Montgomery'ego). Większość kart inteligentnych (na przykład początkowe procesory NXP SmartMX) nadal działa przy użyciu 8-bitowego lub 16-bitowego procesora. Te procesory nie są zaprojektowane do wykonywania operacji na dużych liczbach. Niestety Java Card nie zapewnia bezpośredniej obsługi wywołań do mnożnika - jeśli w ogóle byłaby przydatna. Większość kart (na przykład ponownie SmartMX) również nie obsługuje 32-bitowych operacji (Java int).

Jeśli chcesz wykonać takie obliczenia, musisz je zaprogramować samodzielnie, używając podpisanych 8-bitowych i podpisanych 16-bitowych prymitywów. Będzie to wymagało dużo pracy i będzie bardzo powolne. Dodaj do tego narzut wymagany do przetworzenia kodu bajtowego Java, a będziesz miał niesamowitą ilość powolności.

Źródło

2015-02-14 19:23:26

GF (2) to arytmetyka wielomianowa, w której współprocesor zaprojektowany dla arytmetyki modułowej nie jest nadmiernie użyteczny. Może pomóc w korzystaniu z niektórych rejestrów, jeśli problemem jest brak pamięci RAM, ale zdziwiłbym się, gdyby mógł znacząco przyczynić się do obliczeń. Wcześniejsze procesory Infinity w SEL66 miały ograniczony procesor GF (2). – guidot

Ah, dzięki Guidot, zapomniałem o tym. Jestem sam w F (p). Zakładam, że zgadzasz się, że nie byłoby to szybkie w przypadku 8-bitowej maszyny wirtualnej? –

Po prostu aktualizacja z dodatkowymi informacjami, na wypadek gdyby ktoś nadal szukał rozwiązania.

Lib OpenCryptoJC rzeczywiście zapewnia BigNumbers, operacje prymitywne na krzywej EC itp. Więc powinieneś być w stanie załadować własną krzywą i jej parametry.

Jeśli jednak ta krzywa nie jest obsługiwana natywnie przez kartę, używa się biblioteki do samodzielnego wdrożenia operacji na krzywej. To nie jest banalne ...

Ewentualnie, jeśli istnieje mapowanie między krzywą GF (2^n), której chcesz użyć, a innym GF (p), możesz spróbować wykonać wszystkie operacje w GF (p) i mapują wyniki z powrotem na GF (2^n). Można to łatwiej zrobić, zakładając, że istnieje takie mapowanie.

Zastrzeżenie: Jestem jednym z autorów lib. :)

Źródło

2017-10-02 12:15:46

JavaCard - czysto programowa implementacja ECC ponad GF (2^n)

Odpowiedz

Powiązane problemy