sempre “curiosando” tra i commit, sembra che sia in lavorazione anche la gestione della vaccinazione con Sputnik ma solo se effettuata a San Marino:
2 Mi Piace
Sembra che questo sorgente di esempio usi una libreria in javascript puro per decodificare una firma COSE:
Però non so praticamente niente di moduli javascript dentro pagine web, tutto quello che so fare è…
<script type="module">
import {X509} from 'https://cdn.skypack.dev/jsrsasign';
//console.log("jsrasign",X509);
var c = new X509();
console.log(c);
</script>
Qualche suggerimento?
La chiamata var isValid = pubKey.verify(sMsg, hSig); sembra del tutto identica alla chiamata finale dove va a parare il check dei DCC-UTILS, che ho ricostruito più o meno così:
AlgFromTags[-7] = { 'sign': 'ES256', 'digest': 'SHA-256' };
COSEAlgToNodeAlg = { 'ES256': { 'sign': 'p256', 'digest': 'sha256' }, // .... }; /Only ES256 used in greenpass?
nodeAlg = COSEAlgToNodeAlg[AlgFromTags[alg].sign] // = COSEAlgToNodeAlg[AlgFromTags[-7].sign] = COSEAlgToNodeAlg[ES256] = { 'sign': 'p256', 'digest': 'sha256' }
const hash = crypto.createHash(nodeAlg.digest); // = crypto.createHash('sha256') (CRYPTO library)
hash.update(cbor.encode(SigStructure));
const msgHash = hash.digest();
const pub = { 'x': Buffer.from(signature.pub.x), 'y': Buffer.from(signature.pub.y) }; // Data from public certificate
const ec = new EC(nodeAlg.sign); // = new EC('p256') (Elliptic curve library)
const key = ec.keyFromPublic(pub);
sig = { 'r': sig.slice(0, sig.length / 2), 's': sig.slice(sig.length / 2) }; // Signature is split in 2 halves: R and S
key.verify(msgHash, sig); // Final call to signature check algorithm in Elliptic Curve library
La riga isValid = pubKey.verify(sMsg, hSig); del primo codice sembra proprio “uguale” all’ultima del secondo codice, key.verify(msgHash, sig);… o non c’entra niente?
In ogni caso, questa libreria jsrsasign è quello che mi serve per validare la firma offline e senza NODE.js?
Hanno rilasciato ieri la versione 1.0.2 (Release 1.0.2 · ministero-salute/it-dgc-verificac19-sdk-android · GitHub) con entrambe le modifiche che hai segnalato, grazie!
Ottima notizia.
questa è una roba che andava fatta sin dall’inizio, non mi capacito come possano aver atteso tanto.
Beh, non serve a niente se non ad evitare la figuraccia che il Pass di Hitler risulti valido. Nessuno ha idea di quanti e quali siano quelli falsi, se il modo in cui sono stati generati è l’anteprima…per questo non era stato fatto!
1 Mi Piace
Vero, ma quanto meno, in un caso come quello recente di “Pippo Franco”, tutto sommato può essere utile.
In questo caso è ovvio che se i medici non fanno il loro lavoro e generano x certificati è dura… Garbage-in, Garbage-Out su questo c’è poco da fare ovviamente.
Come funziona questa DenyList (dire blacklist pare politicametne scorretto ormai)?
Si scarica quotidianamente insieme ai dati di convalida delle firme per la verifica offline?
si, la scarica insieme al resto dei parametri (validità di un vaccino post seconda dose etc…)
1 Mi Piace
esatto, è presente nel json con l’elenco delle date di validità dei vaccini/tamponi/sdk version (l’endpoint /settings del ministero) e va confrontata con il certificate id presente nel greenpass.
(qui c’è l’esempio di verifica fatto in php feat: blacklist sdk · herald-si/verificac19-sdk-php@73d91c7 · GitHub)
Quanti certificati ci sono attualmente in BL ?
Al momento ce ne sono 15 e sono i seguenti:
URN:UVCI:01:FR:W7V2BE46QSBJ#L
URN:UVCI:01:FR:T5DWTJYS4ZR8#4
URN:UVCI:01DE/A80013335/TCXSI5Q08B0DIJGMIZJDF#T
URN:UVCI:01:PL:1/AF2AA5873FAF45DFA826B8A01237BDC4
01IT8523A6CADC834919A5214EA30779372D#1
01IT3DA01DD1A0AA4E4E92A10C11B04D39DB#8
01ITD85669BBC8E145FCA9CC83555B413952#3
01ITE901A12151934BAE92D7A537824BA260#3
01IT6E37CB3368F64C6884B3D2A74C266772#0
01ITC9E3B8B6B0344918AE7508E7094D9BCA#7
01ITB00C5897FF354FAFACFAFA391E613F59#8
01IT4C850BC31D3B41329A7EFC1F2AB5D2C5#2
01IT851F1A334C6B450DAD611A5DA4836404#6
01IT8658CD2A96F8435685D63B5C1DBC243F#5
01ITC78D2B44EA9D4C52A77C14C970676B62#9
2 francesi, 1 tedesco, 1 polacco e… 11 italiani! E in quegli 11 non mi risulta ci sia ancora quello di Bettino Craxi…
ok, sono Pippo, Pluto, Paperino e Adolf, forse Pippo Franco, ma per il resto non mi pare che abbiano scoperchiato alcunchè…
Hanno aggiunto da poco quello di Bettino Craxi che è girato in rete. Generato con certificato polacco.
URN:UVCI:01:PL:1/2A992C33754A4D379A7F61089485BB75
Ciao!
lato Ministero hanno aperto un Repository Github per consentire la certificazione di SDK di terze parti.
1 Mi Piace
Mi pare di capire che abbiano praticamente tagliato fuori una possibilità di sviluppare sdk in stile rest/api.
Quindi i vari linguaggi serverside sono stati tagliati fuori se non ho capito male.
Mi viene da pensare come prima cosa PHP tagliato fuori…
Ma la motivaizone di non “inviare” ad esempio il codice QR quale sarebbe? Il pericolo di sniffing? ma se tutto va via https, quali potrebbero essere i pericoli? non capisco.
secondo me - ma è assolutamente una interpretazione - dovrai certificare una “libreria” che poi la tua applicazione server-side utilizza. Vedo che è l’approccio che mi pare stia seguendo astagi nel suo SDK in wip: GitHub - italia/verificac19-sdk: ✅ Official VerificaC19 Node.js SDK
per quanto riguarda la trasmissione dicono:
- Nessuna informazione contenuta nel QR code, né il QR code stesso, deve essere memorizzata, immessa in rete o trasmessa/trattata per finalità diverse dalla verifica.
quindi pensando al “mio” validatorServer, visto che la finalità è appunto la verifica, è lecito inviargli la stringa del QRcode…
Si, questo è vero. Mah, ci sono un paio di cose che mi fanno un po pensare, ci sta che sia tutta una questione di “interpretazione” come dici giustamente tu.
Comunque
- L’intero processo di verifica deve realizzarsi esclusivamente offline in modalità real-time.
- Il risultato della verifica non deve essere utilizzato per finalità non regolamentate dalle norme vigenti.
Nel punto primo, boh, il fatto che debba essere “realtime” e “offline” e “TUTTO” il processo di verifica, mi faceva pensare diversamente.
Nel punto 2, mi viene da pensare che tutti quegli strumenti che ci sono ora che tramite greenpass aprono e chiudono i tornelli di una azienda ad esempio, sono quindi da escludere secondo te?
“TUTTO” il processo di verifica dell’sdk, non dell’applicativo. Significa che i dati devono essere trattati solo all’interno dell’sdk e poi se ne restituisce un set minimo (dati anagrafici ed esito) per essere utilizzati dall’applicazione.
Una volta restituito il set minimo, il processo di verifica è completato.
Per il punto 2, non so nemmeno io come interpretarlo. Penso che per ora possa essere usato solo per ciò che è inserito del DPCM. Il DPCM in realtà dice che devi usarlo per evitare l’accesso in azienda a chi non è in possesso di un GP valido, quindi l’apertura del tornello potrebbe sostituire la validazione tramite verificaC19 e addetto alla porta (ma questa è solo una mia interpretazione).
Ciao
Non so se avete dato un’occhiata alla dichiarazione sostitutiva che va presentata per l’onboarding di una propria libreria… penso non vada preso alla leggera. Si dichiara ad esempio di essere responsabili che il codice “sarà costantemente aggiornato in relazione a eventuali modifiche delle disposizione che ne regolano il funzionamento”.
Questo significa dover “rincorrere” l’SDK ufficiale (visto che l’unico modo attuale per conoscere le regole pare essere guardare i sorgenti e le commit, vedi la recente introduzione del vaccino Sputnik-V per i residenti di San Marino).
Mi chiedo poi: se qualcuno utilizza il mio SDK (visto che è dichiarato “valido”) nella propria applicazione e non lo aggiorno per tempo in base a tali modifiche, sono responsabile di eventuali contestazioni o peggio denunce (es il fatto che l’applicazione che utilizza il mio SDK abbia considerato valido un GP in realtà in blacklist)?
Ho visto che qualcuno si è già mosso per validare la propria libreria (al momento ci sono tre pull-requests) ma non so se tali aspetti siano stati davvero valutati dagli autori (o se sono io che mi faccio troppi problemi 
)
Che ne dite?
1 Mi Piace
Io vedo un grande caos.
Non sto giudicando il lavoro di nessuno, sia chiaro, ma La SDK “ufficiale” è veramente un obrobrio.
(piccolo off-topic, fate attenzione alle vostre app android che implementano la sdk ufficiale, su android 11/12 si rompono qua il ISSUE Bug con Android 11 e Android 12 su progetti con targetSdkVersion 30 · Issue #59 · ministero-salute/it-dgc-verificac19-sdk-android · GitHub)
E per chi lavorerà nel farsi una SDK, seguire quella ufficiale, prevedo dei dolori.
Detto ciò, riguardo a quello che dici tu, a mio avviso, se tu ti affidi ad una SDK esterna il tuo compito è quello di assicurarti che quella SDK stia seguendo la “ufficiale”.
E secondo me, tu che sei il possessore della SDK, fintanto che rimani nella “lista” dei validi, hai l’onere di seguire.
La responsabilità, teoricamente, potrebbe ricadere anche su di te.
Immagino che prevederanno una maniera di essere “revocati” dalla lista, perché se io domani, non ho più voglia, tempo, energie, budget per seguire un progetto, devo avere la possibilità di uscirne.