ZKI mi se razlikuje za xmlsec iz koda i Raverus iz dos prompta

Feb 17, 2013 at 7:48 PM
Kad probam napraviti ZKI iz prompta na Windowsima koristeći Raverus.FiskalizacijaDEV.EXE i kad istu stvar ponovim u svom kodu koriteći xmlsec dobijem različite vrijednosti. U pitanju je Mac pa se md5 računa sa CC_MD5() iz CommonCrypto. Identična md5 vrijednost se dobije i kad koristim openssl - MD5_Init(), MD5_Update() i MD5_Final().

Ima neko ideju gdje griješim?
#import <CommonCrypto/CommonDigest.h>

int  encodeString2 (const char *cert_file, char *password, char *inStr, char *outStr)
{
   xmlSecTransformCtxPtr  t_ctx;
   xmlSecTransformCtx     transformCtx;
   xmlSecTransformPtr     signMethod;
   xmlSecByte            *dataPtr;
   
   size_t                 dataSize;
   int                    i;
   xmlSecTransformId      rsa_sha1MethodId;
   unsigned
    char                  aDigest[16];
   xmlSecDSigCtxPtr       dsigCtx = NULL;
   unsigned
    char                  tmpStr[1024];  // umjesto S:String

   int         res = -1;

   // begin
         
   // xmlSecInit ();  // done outside!
   
   
   dataPtr  = (xmlSecByte *)inStr;
   dataSize = strlen (inStr);
   
   memset (&transformCtx, 0, dataSize);  // was  FillChar (transformCtx, SizeOf(transformCtx), #0);
   
   t_ctx = &transformCtx;
   
   xmlSecTransformCtxInitialize (t_ctx);
   
   dsigCtx = xmlSecDSigCtxCreate (NULL);
   
   if (dsigCtx == NULL)  {
      fprintf (stderr,"Error: failed to create signature context (ZK)\n");
      
      goto  done;
   }
      
   //  ucitaj privatni kljuc
      
   dsigCtx->signKey = xmlSecCryptoAppKeyLoad (cert_file, xmlSecKeyDataFormatPkcs12, password, NULL, NULL);
      
   if (dsigCtx->signKey == NULL)  {
      fprintf (stderr,"Error: failed to load private pem key from '%s' Maybe password is wrong (ZK) ?\n", cert_file);
      goto  done;
   }

   rsa_sha1MethodId = xmlSecTransformRsaSha1Id;  // xmlSecTransformRsaSha1GetKlass ();
   
   signMethod = xmlSecTransformCtxCreateAndAppend (t_ctx, rsa_sha1MethodId);
   
   if (dsigCtx->signKey == NULL)  {
      fprintf (stderr,"Error: failed xmlSecTransformCtxCreateAndAppend call!\n");
      goto  done;
   }
   
   signMethod->operation = xmlSecTransformOperationSign;
   
   i = xmlSecTransformSetKey (signMethod, dsigCtx->signKey);
   
   if (i < 0)  {
      fprintf (stderr,"Error: xmlSecTransformSetKey failed %d!\n", i);
      goto  done;
   }

   i = xmlSecTransformCtxPrepare (t_ctx, xmlSecTransformDataTypeBin);
   
   if (i < 0)  {
      fprintf (stderr,"Error: xmlSecTransformCtxPrepare failed %d!\n", i);
      goto  done;
   }

   i = xmlSecTransformDefaultPushBin (t_ctx->first, dataPtr, (xmlSecSize)dataSize, 1, t_ctx);
   
   if (i < 0)  {
      fprintf (stderr,"Error: xmlSecTransformDefaultPushBin failed %d!\n", i);
      goto  done;
   }
   
   memmove (tmpStr, t_ctx->result->data, t_ctx->result->size);
   tmpStr[t_ctx->result->size] = '\0';
   
   if (!tmpStr[0])  {
      fprintf (stderr,"Error: BUG! result is empty!\n");
      goto  done;
   }
   
   CC_MD5 (tmpStr, (CC_LONG)strlen((char *)tmpStr), aDigest);
      
   
   for (i=0; i<16; i++)
      sprintf (outStr+(i*2), "%02x", (int)aDigest[i]);


   t_ctx->status = xmlSecTransformStatusFinished;

   res = 0;

done:
   
   if (dsigCtx)
      xmlSecDSigCtxDestroy (dsigCtx);
   
   // xmlSecShutdown ();  // Eh! Already done outside!
   
   return (res);
}
Feb 18, 2013 at 9:03 AM
Ne znam za Mac, mi smo imali slučaj na win OS-u da ako podatke za ZKI popunjavamo iz c# forme ne dobijemo uvijek isti ZKI u odnosu na onaj koji popunjavamo kroz files. Zauzeli smo stav da je najbolje uvijek generirati ZKI na isti način, naravno ako je to moguće. Tako uvjek dobijemo isti ZKI.. vremenski se ne stigne izučavati zašto se to događa. Funkciju za izračun ZKI-a smo radili prema primjeru koji je dao Apis a i u ovom projektu mislim da je isti pristup.
Coordinator
Feb 18, 2013 at 9:11 AM
ZKI bi uvijek morao biti isti ako se koristi identičan algoritam :)
Kao zgodan tool koji se može koristiti, između ostalog, i za provjeru (verifikaciju algoritma) ZKI pogledajte: https://www.fdev.hr/Explorer/FDev-Explorer.aspx
Feb 19, 2013 at 12:00 AM
Edited Feb 19, 2013 at 1:21 PM
ZKI bi uvijek morao biti isti ako se koristi identičan algoritam :)
To sam i ja očekivao. Da li je itko tko koristi xmlsec dobio isti ZKI kad ga usporedi sa recimo Raverus aplikacijom?
Jun 20, 2013 at 12:27 PM
abranko wrote:
Zauzeli smo stav da je najbolje uvijek generirati ZKI na isti način, naravno ako je to moguće. Tako uvjek dobijemo isti ZKI...
Pozdrav,

Što to konkretno znači?
Ako dva sustava na osnovu istih parametara kreiraju dva različita ZKI-a kako znati koji je ispravan?
Da li ZKI može biti i pogrešan dokle god je ZKI na računu kupca jednak ZKI prijavljenom poreznoj?

pozdrav
Jun 20, 2013 at 1:04 PM
Edited Jun 20, 2013 at 1:06 PM
Ma mora dati isti ZKI. Nešto ne štima u tvom kodu. Imali smo slučaj na WINos tj. Delphiju ( opisan je u jednom od thread-a ) sa lošom definiciom buffera pa nam je bio odrezan dio buffera tako da je krivo generiran ZKI ( sa skračenim bufferom ).

Uglavnom MORAŠ dobiti isti rezultat kao i u Raverusu. Po tome onda ni porezna ne bi mogla pretraživat račun po ZKI-u.
Jun 20, 2013 at 1:22 PM
tZac wrote:
Uglavnom MORAŠ dobiti isti rezultat kao i u Raverusu. Po tome onda ni porezna ne bi mogla pretraživat račun po ZKI-u.
Zašto ne? Ako pogrešan ZKI daš kupcu i pogrešan ZKI (ali isti kao onaj koji si dao kupcu) prijaviš poreznoj tada i porezna i kupac imaju isti ZKI. Jedino je problem što taj ZKI nije ispravno kreiran od ispravnih parametara. Moje je pitanje bilo da li je to problem!?

Dakle moje pitanje glasi: da li je pogrešno i nedozvoljeno kupcu i poreznoj dati ISTI ZKI koji je izračunat na pogrešan način?

lijepi pozdrav
Jun 20, 2013 at 1:32 PM
U testnom okruženju u poruku prijave računa stavio sam ZKI koji nema nikakve veze sa ostalim parametrima poruke (stavio sam ZKI napravljen drugim certifikatom, za drugi račun, na drugi datum i drugi iznos bla, bla...) i uredno dobio JIR...

dakle, pitanje nije tehničke prirode jer stvar radi. Pitanje je očigledno smije li se to ili ne. Pretpostavljam da ne jer onda sami ZKI nebi imao smisla. Ili se varam?
Jun 20, 2013 at 1:38 PM
Ovo ti je najbolje poslat poreznoj ili u Apis pa vidit što će odgovorit. Po meni je logično da je i ZKI element zaštite tako da bi se on i na strani porezne uprave trebao generirat od strane njih, pa uparit s našim, a ne da se samo uzima naš broj bezuvjetno. Ali kao što kažeš očito kod njih te kontrole nema
Jun 20, 2013 at 2:13 PM
Pričekajmo, možda netko ima neku ideju.
Ja ću još dodatno provjeriti kod sebe sa još nekoliko random ZKI-eva za svaki slučaj.

Pozdrav
Jun 20, 2013 at 2:30 PM
Edited Jun 20, 2013 at 2:50 PM
Naravno da isti algoritam mora dati isti rezultat.
Svojevremeno sam proučavao jednostavniji SHA algoritm. Stvar je u tome da ni MD5 nema, po mojim saznanjima, reverzibilan proces izračunavanja izvornih podataka na temelju rezultantnog hash broja (ZKI). Zato se algoritam za izračunavanje ZKI-a vjerojatno testira "rubber duck" metodom. https://en.wikipedia.org/wiki/Rubber_duck_debugging Pogotovo kad se surađuje sa CommonCrypto ili NETFramework. To će svakako bolje znat netko tko je pisao MD5 alg.
Možda uzeti neki drugi program u nadi de će dati isti ZKI.

P.S.
Načelno, račun ne bi smio sadržavat netočne podatke. Čak i oni koji nisu obavezni moraju biti točni.
Jun 20, 2013 at 2:52 PM
Edited Jun 20, 2013 at 2:53 PM
ZKI se dijelom izračunava i iz certifikata. Kako certifikat ima samo korisnik, porezna ne može izračunati ZKI bez da ukrade korisniku certifikat. Ako je ZKI u ispravnom formatu, jedinstven je i možeš ga ponovo izračunati iz svoje aplikacije sa korisnikovim certifikatom onda ne bi smjelo biti problema (i nitko ne može znati da je ZKI "kriv").
Jun 20, 2013 at 3:15 PM
moremore wrote:
ZKI se dijelom izračunava i iz certifikata. Kako certifikat ima samo korisnik, porezna ne može izračunati ZKI bez da ukrade korisniku certifikat. Ako je ZKI u ispravnom formatu, jedinstven je i možeš ga ponovo izračunati iz svoje aplikacije sa korisnikovim certifikatom onda ne bi smjelo biti problema (i nitko ne može znati da je ZKI "kriv").
Znači može biti pogrešan dokle god je čovjek dosljedan u načinu na koji je pogrešan... pa to bi bilo krasno...
Jun 21, 2013 at 9:29 AM
Pa, u principu je tako :)
Jun 21, 2013 at 11:39 PM
Ja sam pokrenuo ovu temu i u međuvremenu sam zaboravio na nju.

Kao informacija, na kraju sam dobio da sve radi uredno, Mac/xmlsec mi sad proizvodi jednaki ZKI kao i Raverus na Windowsima. Znam da sam dugo po tome petljao i na kraju kad je sve proradilo više nisam siguran ni zašto radi ni zašto prije nije. Moguće da OpenSSL ima neke bugove koji se manifestiraju u određenim okolnostima.