PAdES LTV bizonyítékok és seed értékek a HotPDF-ben

Az imént aláírt PDF egy B-B aláírás, és semmi több. Bizonyítja, hogy ki írt alá, és hogy a bájtok nem mozdultak, de nem hordoz bizonyítékot arra, hogy az aláíró tanúsítvány érvényes volt az aláírás időpontjában, tehát egy évekkel későbbi ellenőrzőnek el kell indulnia visszavonási adatok után, amelyek már nem is létezhetnek. A rés bezárása azt jelenti, hogy OCSP válaszokat és CRL-eket ír a dokumentumszintű Document Security Store-ba, és a HotPDF-ben ez egyetlen hívás: a PopulatePAdESLTVEvidence végigmegy minden betöltött aláíráson, a visszavonási kéréseket a tanúsítványkészletből levezeti, egy Ön által szolgáltatott transporton keresztül végrehajtja őket, és a letöltött anyagot plusz a CMS láncot a DSS-be írja. Visszaadja azon aláírások számát, amelyek bizonyítéka megérkezett, vagy mínusz egyet, amikor a dokumentumnak egyáltalán nincs aláírási mezője

A tervezési döntés, amelyet érdemes megérteni, mielőtt használná, az, hogy a függvénytár soha nem nyit socketet. Minden bájt, amely a hálózatból érkezik, egy Ön által írt visszahíváson át érkezik. Ez nem óvatosság öncélból; ez az egyetlen mód annak, hogy ez a funkció működhessen azokban a környezetekben, amelyek valóban megkövetelik a hosszú távú érvényesítést

Miért utasítja el a függvénytár, hogy saját HTTP-t végezzen?

Mert a helyek, amelyek B-LT aláírásokat követelnek, azok a helyek, ahol egy függvénytárra nem lehet a hálózatot bízni. Az aláíró szolgáltatások hitelesítő proxyk mögött futnak vállalati gyökerekkel. A légmentesen zárt aláíró rétegeknek nincs útjuk a válaszadóhoz, és gyorsítótárazott bizonyítékkal kell őket táplálni. Az auditrendszerek megkövetelik, hogy minden kimenő kérést az alkalmazás naplózzon, ne egy függőség temessen el. És a tesztcsomagoknak determinisztikus válaszokra van szükségük, ami lehetetlen, ha a függvénytár saját maga tárcsázza ki

A transport egy sima függvényhivatkozás rögzített alakkal, tehát a politika az Öné marad. A HotPDF átad egy kérésrekordot, amely pontosan leírja, mit kell letölteni, a tartalomtípust és a válaszméret-korlátot is beleértve, és Ön a bájtokat adja vissza egy státusszal együtt

function FetchEvidence(const Request: THPDFSignatureEvidenceRequest;
  Attempt: Integer; CancellationToken: THPDFCancellationToken;
  out Response: TBytes; out RetryAfterMS: Cardinal;
  out ErrorMessage: UnicodeString): THPDFSignatureEvidenceTransportStatus;
begin
  RetryAfterMS := 0;
  try
    // A Request.Kind mondja meg, hogy ez OCSP POST vagy CRL GET;
    // a Request.ContentType és a Request.Body már elő vannak készítve,
    // és a Request.MaxResponseBytes az a korlát, amelyet be kell tartania
    Response := HttpExchange(Request.URI, Request.ContentType,
      Request.Body, Request.MaxResponseBytes);
    Result := setsSucceeded;
  except
    on E: Exception do
    begin
      ErrorMessage := E.Message;
      // A setsRetry engedi, hogy az újrapróbálozási politika visszavonuljon;
      // 404-re vagy rossz URL-re használja a setsPermanentFailure-t
      Result := setsRetry;
    end;
  end;
end;

// Egyhívásos B-B-ről B-LT-re frissítés a betöltött fájl minden aláírására
var
  Pdf: THotPDF;
  Upgraded: Integer;
begin
  Pdf := THotPDF.Create(nil);
  try
    Pdf.BeginIncrementalUpdate('signed.pdf');
    Upgraded := Pdf.PopulatePAdESLTVEvidence(FetchEvidence,
      THPDFSignatureEvidenceRetryPolicy.Default);
    if Upgraded > 0 then
      // Csak-hozzáfűzéses mentés: a meglévő aláírások által fedett
      // bájtok szó szerint megőrződnek
      Pdf.SaveIncrementalUpdate('signed-lt.pdf');
  finally
    Pdf.Free;
  end;
end;

A hibák aláírásonkéntiek, nem dokumentumonkéntiek. Egy egyetlen aláíróra időtúllépő válaszadó kihagyja annak az aláírónak az anyagát, és a menet többi részét érintetlenül hagyja, ami az a viselkedés, amelyet egy kötegben szeretne: a részleges bizonyíték többet ér egy megszakított futásnál, és a visszatérési érték megmondja, hány aláírás javult ténylegesen

A lánc, amelyet a CMS elfelejtett belefoglalni

A visszavonás-ellenőrzésnek szüksége van a kibocsátó tanúsítványra, és meglepően sok aláíró készlet kihagyja a közbülsőket a CMS tárolóból. A visszanyerési út az Authority Information Access kiterjesztés, a 1.3.6.1.5.5.7.48.2 hozzáférési módszer, amely egy URL-t hirdet, ahonnan a kibocsátói tanúsítvány letölthető. A HPDFFetchAIAIntermediates ugyanazon transporton megy végig azokon az URL-eken, mindegyik válaszból kiéri a DER-t, és csak azokat a tanúsítványokat adja vissza, amelyeket a CMS még nem hordozott, DER hash alapján kulcsolva, hogy a duplikátumok és a körök ne pörögjenek

Két részlet dönti el, hogy ez működik-e valós tanúsítványhatóságok ellen. Az első a kódolás: a CA végpontok nagyjából ugyanolyan gyakran szolgálják ki a tanúsítványt csupasz DER-ként, mint PEM-páncélban, és nincs megbízható tartalomtípus a megkülönböztetésükre. A robusztus szonda szöveges, majd szerkezeti. Keresse a -----BEGIN CERTIFICATE----- jelzőt, ha jelen van, tépje le a páncélt, és dekódolja a base64-et, és mindkét úton erősítse meg, hogy az eredmény első bájtja $30, a DER SEQUENCE tagje. A második a mélység: egy letöltött közbülső maga is hirdethet AIA URL-t a saját kibocsátójának, tehát a bejárás új jelölteket fűz a sorhoz, és befejezi azokat a láncokat, amelyek két-három ugrással rövidek. Ezt korlátozni kell, amire a MaxFetch paraméter való

Mi az aláírás seed értéke, és miért hibázik csendben?

A seed érték olyan megszorítás, amelyet a dokumentum szerzője egy aláírási mezőhöz csatol, hogy megmondja az aláírónak, milyen aláírás elfogadható: melyik SubFilter, melyik kivonatoló algoritmus, mely indokok, mely minimális PDF verzió, és be kell-e ágyazni a visszavonási információt. A mező /SV szótárában él, és az ISO 32000-1 §12.7.5.5 definiálja. A HotPDF az AttachPAdESSeedValue metódussal írja, és a CheckLoadedSignatureSeedValue metódussal ellenőrzi, amely True értéket ad, amikor a mező korlátlan, vagy minden jelen lévő megszorítás teljesül, és False esetén az első megbukó megszorítást nevezi meg egy kimeneti paraméterben, amelyet közvetlenül hibaüzenetbe tehet

A mechanizmus, amely miatt a seed értékeket könnyű elrontani, a §12.7.5.5.3-ban leírt /Ff jelzőbejegyzés. A beállított bit megszorítását kötelezőként jelöli: az eltérés hiba, és az aláírónak el kell utasítania. A tiszta bit ugyanazt a megszorítást preferenciaként jelöli: az érték kiszűri, amit a felület kínálhatna, és semmi több. Ebből két csapda következik. Először, a /Ff a /SV szótáron belül él, nem a widget annotáción, tehát a mezőszintű /Ff-t olvasó kód örökre üres választ kap, és arra a következtetésre jut, hogy semmi nincs kikényszerítve. Másodszor, a bit-hozzárendelések nem egyszerű egy-két-négy-nyolc sor; a HotPDF-ben az író 2-t bocsát ki SubFilterre, 4-et MinVersionre, 32-t AddRevInfo-ra és 64-et DigestMethodra. Az olyan olvasó, amely szekvenciális biteket feltételez, minden megszorítást opcionálisként dekódol, és minden teszten átmegy, kivéve a fontoson

var
  Violation: AnsiString;
begin
  // Kérdezze meg a mezőtől, hogy engedélyezett-e a profil, amellyel aláírni készülünk
  if not Pdf.CheckLoadedSignatureSeedValue(0, 'ETSI.CAdES.detached',
       'SHA256', 'Approved for payment', 1, Violation) then
    raise Exception.Create('Signature field rejects this profile: ' +
      String(Violation));
  // Megszorítás teljesült: folytatás az aláíró menettel
end;

Az a teszt, amely felfedte az eredeti dekódolási hibát, nem pozitív teszt volt. Az volt az állítás, hogy egy kikényszerített eltérést el kell utasítani, és ez az egyetlen tesztfajta, amely el tudja fogni ezt a hibaosztályt: egy rossz szótárt vagy rossz bitpozíciókat olvasó dekódoló minden bemenetre azt adja, hogy „nincs megsértett megszorítás”, ami pontosan úgy néz ki, mint a helyes viselkedés, amíg szándékosan meg nem sértenek egyet

Hol áll ez az LTV létrán

Négy fok, és mindegyiknek kell az alatta lévő. A B-B a csupasz aláírás. A B-T hozzáad egy megbízható időbélyeget, amely rögzíti az aláírási időt, hogy az ellenőrző tudja, melyik pillanathoz kell a visszavonást értékelnie. A B-LT hozzáadja a visszavonási bizonyítékot a DSS-hez, amit a PopulatePAdESLTVEvidence automatizál. A B-LTA hozzáadja azokat a dokumentum-időbélyegeket, amelyeket az előző meggyengülése előtt megújítanak, az érvényességet határozatlan ideig nyújtva; a HotPDF ezt RenewPAdESLTATimestamp néven teszi elérhetővé, amely új időbélyeget fűz inkrementális revízióként, és minden korábbi aláírást, időbélyeget és DSS bejegyzést érintetlenül hagy

Az inkrementális frissítési modell az egyetlen helyes mód annak, hogy bizonyítékot adjunk egy aláírt dokumentumhoz, mert a fájl átírása megtörné azokat a bájtartományokat, amelyeket a meglévő aláírások fednek. Ha érvelnie kell arról, hogy mi változott a revíziók között, és hogy azok a változások olyanok-e, amelyeket egy aláírás megenged, azt az elemzést külön tárgyalja a DocMDP és FieldMDP revízióelemzés. Maga az aláíró vezeték, a tanúsítványforrásokkal és a bájtsorrend buktatóival együtt, a PAdES aláírási útmutatóban van, az érvényesítési oldal pedig a betöltött dokumentumok aláírásainak ellenőrzésében

Egy gyakorlati figyelmeztetés a sorrendhez. Gyűjtse a bizonyítékot az aláírás után minél előbb, ideálisan ugyanabban a feladatban. Azok a válaszadók, amelyek egy tanúsítványért felelhetnek, online vannak, amíg a tanúsítvány aktuális, és évek múlva eltűnnek, tehát egy olyan dokumentum, amely B-B-ként hagyja el az Ön vezetékét, lehet, hogy soha többé nem frissíthető. A HotPDF natív VCL komponensként fut Delphi és C++Builder rendszerekhez, és a teljes bizonyítékmene a saját folyamatában fut, kivéve az Ön transportját; a támogatott profilok a HotPDF Delphi PDF component terméklapon találhatók