Sprawdzanie podpisu SHA1withECDSA na javacard

Question

Mam podpisany przez siebie certyfikat podpisany przez algorytm SHA1withECDSA przy użyciu BouncyCastle. Pod BC mogę to łatwo zweryfikować, ale kiedy robię to na JavaCard, wysyłam fałszywe za każdym razem (Curve secp192r1 od NIST). Zaświadczenie o zawieszeniu certyfikatu (bez X9.62 oznacza po prostu r + s bez żadnych TAGów).

Jest mój kod do weryfikacji (z wartościami ustawionymi jako stałe - oczywiście dla testów).

bajt [] certdata = {...}

Signature signature = Signature.getInstance(Signature.ALG_ECDSA_SHA, false); 
    ECPublicKey ecpk = (ECPublicKey) KeyBuilder.buildKey(KeyBuilder.TYPE_EC_FP_PUBLIC,  KeyBuilder.LENGTH_EC_FP_192, true); 

    ecpk.setA(new byte[]{...}, (short)0, (short)0x0018); 
    ecpk.setB(new byte[]{...}, (short)0, (short)0x0018); 
    ecpk.setG(new byte[]{...}, (short)0, (short)0x0031); 
    //Point format: uncompressed tag(0x04), x, y 
    ecpk.setK((short)0x0001); 
    ecpk.setR(new byte[]{}, (short)0, (short)0x0018); 
    ecpk.setW(new byte[]{}, (short)0, (short)0x31); 
    ecpk.setFieldFP(new byte[]{}, (short)0, (short)0x0018); 

    signature.init(ecpk, Signature.MODE_VERIFY); 

    boolean result = signature.verify(certdata, (short)0, (short)certdata.length, signtab, (short)0, (short)signtab.length); 
    if(result) ISOException.throwIt((short)0x0001); 
    else ISOException.throwIt((short)0x0002);  
} 

'...' zamiast bajtów widoczność (192bits Krzywą do bałagan).

Certyfikat z etykietkami wyjaśnienie pastebin:

http://pastebin.com/gvqYzm2g

dzięki za pomoc

Sevar

EDIT: Nowe testy: Wszystkie testy ponownie na tych samych danych (PublicKey, PrivateKey , Wiadomość do podpisu) znak jest losowy, więc użyję 2 znaków (signT - znak wygenerowany przez Terminal (BC), signC - znak wygeneruje d by Chip)

nie można zweryfikować na CHIP, ale można sprawdzić na Terminalu. signC jest weryfikowana na chipie & Terminal

więc sprawdziłem krzyż między API

• Krzyż Relacja skierowany do BC działa dobrze

• Krzyż Relacja skierowany do chip nie działa

para kluczy generowanych również, ponieważ po umieszczeniu klucza prywatnego i klucza publicznego wygenerowanego przez BC na CHIP, a następnie s ignacja wygenerowana na CHIP może być zweryfikowana przez CHIP.

• parę kluczy generowane dobrze

nie mam pojęcia, co powinienem sprawdzić teraz. Prawdopodobnie problem może dotyczyć wypełniania macierzy w kroku ECDSA e = SHA1 (Wiadomość). Co dzieje się z tablicą po haszowaniu (skrót jest krótszy od krzywej, a karta musi zadeklarować rozmiar tablicy przed kopiowaniem)

Answer 1

Podpisanie i weryfikacja ECDSAwithSHA-1 z Prime192v1 z Bouncy Castle na JavaCard działa dobrze dla mnie.

Twoim problemem jest prawdopodobnie format samego podpisu.

Podpis jest strukturą kodowaną DER, jest to sekwencja (znacznik 0x30) dwóch liczb całkowitych (znacznik 0x02). W JavaCard zawsze oczekuje się 56 bajtów: dwie współrzędne długości 25 plus 6 bajtów nagłówków DER. JavaCard zawsze oczekuje początkowych zer w każdej współrzędnej.Jednak BC często tworzy sygnatury bez wiodących zer we współrzędnych, więc sygnatura może być krótsza niż 56 bajtów i dlatego JavaCard jest zdezorientowany.

Kierunek przeciwny jest zawsze OK, ponieważ BC może obsługiwać zera wiodące, chociaż nie dodaje ich podczas tworzenia podpisu.

Co należy zrobić: zawiń mechanizm podpisu BC własnym kodem i ZAWSZE dodaj zera wiodące do współrzędnych w sygnaturze BC. Jeśli to zrobisz, będziesz w stanie zweryfikować podpis zarówno w BC i JavaCard.

chciałbym pisać mojego kodu, ale niestety to jest częścią projektu komercyjnego bezpieczeństwa ...

Answer 2

miałem problem z verifinge w singature ECDSA (wygenerowany na JavaCard 192r1) używając BouncyCastle i znalazłem rozwiązanie. Mam nadzieję, że będzie użyteczny

Verify javacard signature ALG_ECDSA_SHA on bouncy castle