2015-02-12 9 views
7

ho smartcard di NXP che supportano ECC su GF (p) e che non supportano ECC su GF (2^n).JavaCard - pura implementazione software di ECC su GF (2^n)

Nel mio progetto ho bisogno di utilizzare questo particolare tipo di smartcard (già utilizzate migliaia di istanze). Tuttavia, ho bisogno di aggiungere la verifica della firma EC su sect193r1, che è una curva su GF (2^n).

Le prestazioni non sono un problema per me. Ci può volere del tempo La verifica della firma non comporta alcuna chiave privata, quindi anche la sicurezza e la gestione delle chiavi non sono problemi. Sfortunatamente, devo verificare la firma all'interno della mia smartcard, non nel dispositivo dotato di lettore di smartcard.

C'è qualche soluzione? Esiste un codice sorgente esistente di una pura implementazione JavaCard del software della crittografia EC su GF (2^n)?

+2

Verificherei prima se entrambe le implementazioni software JCRE e Reader che stai utilizzando supportano un numero illimitato di estensioni di attesa sul sottostante strato di protocollo 7816/14443, poiché sarà quasi sempre indovinato –

+1

@PaulBastian La maggior parte delle implementazioni I vedi avere un buon supporto WTX al giorno d'oggi, ma sono d'accordo, non importa se semplicemente non ritorna mai :) –

+0

@MaartenBodewes Ok, sembra pessimo: -) ... Per "le prestazioni non sono un problema" intendevo qualcosa come "3 secondi sono OK". Bene, questa sembra essere una battaglia persa. Grazie per tutte le risposte! – vojta

risposta

3

Le smart card che sono in grado di eseguire la crittografia asimmetrica sempre fare questo usando un co-processore (che di solito contiene un moltiplicatore Montgomery). La maggior parte delle smart card (ad esempio i processori NXP SmartMX iniziali) funzionano ancora utilizzando una CPU a 8 o 16 bit. Quelle CPU non sono progettate per eseguire operazioni su grandi numeri. Sfortunatamente la Java Card non fornisce supporto diretto per le chiamate al moltiplicatore - se ciò sarebbe del tutto inutile. La maggior parte delle carte (ad esempio ancora lo SmartMX) non supporta le operazioni a 32 bit (Java int).

Quindi, se si desidera eseguire questi calcoli si dovrà programmare da soli, utilizzando firmato 8 bit e firmato 16 primitive bit. Ciò richiederà molto lavoro e sarà molto lento. Aggiungete a ciò il sovraccarico necessario per elaborare il codice byte Java e avrete un'incredibile quantità di lentezza.

+1

GF (2) è l'aritmetica polinomiale, in cui il coprocessore progettato per l'aritmetica modulare non è eccessivamente utile. Potrebbe essere utile utilizzare alcuni dei suoi registri se il problema è la carenza di RAM, ma sarei sorpreso, se può contribuire in modo significativo al calcolo. I primi processori SEL66 di Infineon avevano un co-processore GF (2) limitato. – guidot

+0

Ah, grazie guidot, ci siamo dimenticati. Sono rigorosamente su F (p) me stesso. Suppongo tu sia d'accordo sul fatto che questo non sarebbe veloce su una macchina virtuale a 8 bit? –

1

Aggiornamento con alcune informazioni aggiuntive nel caso in cui qualcuno sia ancora alla ricerca di una soluzione.

L'OpenCryptoJC lib fornisce infatti BigNumbers, curva operazioni primitive CE ecc Quindi si dovrebbe essere in grado di caricare la propria curva ed i suoi parametri.

Tuttavia, se questa curva non è supportato nativamente dalla scheda, è possibile utilizzare il lib per attuare le operazioni sulla curva da soli. Questo non è banale anche se ...

In alternativa, se non v'è alcuna corrispondenza tra il GF (2^n) della curva che si desidera utilizzare e un altro GF (p) si potrebbe provare fare tutte le operazioni in GF (p) e li mappano i risultati su GF (2^n). Questo potrebbe essere più facile da fare supponendo che ci sia una tale mappatura.

Disclaimer: io sono uno dei lib autori. :)

Problemi correlati