Teknik Makale

HotPDF'de PAdES LTV Kanıtı ve Seed Değerleri

Az önce imzaladığınız bir PDF, bir B-B imzasıdır ve ötesi değildir. Kimin imzaladığını ve baytların yerinden oynamadığını kanıtlar ama imzalayan sertifikasının imzalama anında geçerli olduğuna dair kanıt taşımaz; dolayısıyla yıllar sonra bir doğrulayıcı, o zamandan kalmış olmayabilecek yoksun bırakma verisini aramak zorunda kalır. O boşluğu kapatmak, OCSP yanıtlarını ve CRL'leri belge düzeyindeki Document Security Store'a yazmak demektir ve HotPDF'de bu tek bir çağrıdır: PopulatePAdESLTVEvidence yüklenen her imzayı dolaşır, yoksun bırakma isteklerini sertifika kümesinden türetir, bunları sizin sağladığınız bir taşıma üzerinden yürütür ve getirilen malzemeyi CMS zinciriyle birlikte DSS'e yazar. Kanıtı yerleşen imzaların sayısını döndürür; belgede hiç imza alanı yoksa eksi bir döndürür

Kullanmadan önce anlaşmaya değer tasarım kararı şudur: kitaplık asla soket açmaz. Ağdan gelen her bayt, sizin yazdığınız bir geri çağrıdan geçerek gelir. Bu kendi başına temkinlilik değildir; bu özelliğin uzun süreli doğrulamayı gerçekten talep eden ortamların içinde çalışabilmesinin tek yoludur

Kitaplık kendi HTTP işini yapmayı neden reddediyor?

Çünkü B-LT imzaları talep eden yerler, bir kitaplığa ağ konusunda güvenilemeyen yerlerdir. İmzalama hizmetleri, kurumsal kökleri olan kimlik doğrulayan vekil sunucuların arkasında çalışır. Ağdan kopuk imzalama katmanlarının bir yanıtlayıcıya yolu yoktur ve önbelleğe alınmış kanıtla beslenmeleri gerekir. Denetim rejimleri, her giden isteğin uygulamaca günlüğe yazılmasını gerektirir; bir bağımlılığın içine gömülmesini değil. Ve test takımları belirli yanıtlar ister; kitaplık kendi başına dışarı çevrirse bu imkânsızdır

Taşıma, sabit bir biçimi olan düz bir işlev referansıdır; böylece politika sizde kalır. HotPDF size tam olarak neyin getirileceğini anlatan bir istek kaydı verir; içerik türü ve bir yanıt boyutu sınırı dahil. Siz de baytları bir durumla birlikte döndürürsünüz

HotPDF PopulatePAdESLTVEvidence akışı: çağıranın sağladığı FetchEvidence taşıması, istek kaydı alanları ve imza başına durum sonuçları
Her ağ baytı sizin FetchEvidence geri çağrınızdan geçer ve her imza kendi durumunu alır; böylece bir zaman aşımı hiçbir zaman geçişi durdurmaz
function FetchEvidence(const Request: THPDFSignatureEvidenceRequest;
  Attempt: Integer; CancellationToken: THPDFCancellationToken;
  out Response: TBytes; out RetryAfterMS: Cardinal;
  out ErrorMessage: UnicodeString): THPDFSignatureEvidenceTransportStatus;
begin
  RetryAfterMS := 0;
  try
    // Request.Kind bunun bir OCSP POST mu yoksa CRL GET mi olduğunu söyler;
    // Request.ContentType ve Request.Body hazır olarak gelir,
    // Request.MaxResponseBytes ise uymak zorunda olduğunuz sınırdır
    Response := HttpExchange(Request.URI, Request.ContentType,
      Request.Body, Request.MaxResponseBytes);
    Result := setsSucceeded;
  except
    on E: Exception do
    begin
      ErrorMessage := E.Message;
      // setsRetry yeniden deneme politikasının geri çekilmesini sağlar;
      // 404 ya da bozuk bir URL için setsPermanentFailure kullanın
      Result := setsRetry;
    end;
  end;
end;

// B-B'den B-LT'ye tek çağrılık yükseltme, yüklenen dosyadaki her imza için
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
      // Yalnızca eklemeli kaydetme: mevcut imzaların kapsadığı baytlar
      // aynen korunur
      Pdf.SaveIncrementalUpdate('signed-lt.pdf');
  finally
    Pdf.Free;
  end;
end;

Başarısızlıklar belge başına değil, imza başınadır. Bir imzalayan için zaman aşımına uğrayan yanıtlayıcı, o imzalayanın malzemesini atlar ve geçişin geri kalanını sağlam bırakır; bu da bir toplu işte isteyeceğiniz davranıştır: kısmi kanıt, yarıda kesilmiş bir çalışmadan iyidir ve dönüş değeri gerçekte kaç imzanın iyileştiğini söyler

CMS'in eklemeyi unuttuğu zincir

Yoksun bırakma denetimi, veren sertifikayı gerektirir ve şaşırtıcı sayıda imzalama yığını, ara sertifikaları CMS kapsayıcısının dışında bırakır. Kurtarma yolu, Authority Information Access uzantısıdır; erişim yöntemi 1.3.6.1.5.5.7.48.2 olup veren sertifikasının indirilebileceği bir URL duyurur. HPDFFetchAIAIntermediates, o URL'leri aynı taşıma üzerinden dolaşır, her yanıttan DER'i ayrıştırır ve yalnızca CMS'in zaten taşımadığı sertifikaları döndürür; DER karmasına göre anahtarlanır, böylece kopyalar ve döngüler dönüp duramaz

İki ayrıntı, bunun gerçek sertifika otoritelerine karşı çalışıp çalışmayacağına karar verir. İlki kodlamadır: CA uç noktaları sertifikayı PEM zırhlısı olarak sundukları kadar çıplak DER olarak da sunar ve onları ayırt edecek güvenilir bir içerik türü yoktur. Sağlam yoklama önce metinsel, sonra yapısal olandır. -----BEGIN CERTIFICATE----- işaretine bakın, zırh varsa soyun ve base64 çözün; her iki yolda da sonucun ilk baytının, bir SEQUENCE'ın DER etiketi olan $30 olduğunu doğrulayın. İkincisi derinliktir: getirilen bir ara sertifika kendi veren için de bir AIA URL duyurabilir; dolayısıyla yürüyüş kuyruğa yeni adaylar ekler ve iki üç atlama eksiği olan zincirleri tamamlar. Bunun sınırlandırılması gerekir; MaxFetch parametresi bunun içindir

HotPDF için AIA zincir tamamlama şeması: caIssuers URL getirme, PEM ile DER yoklaması, DER karması tekilleştirme ve MaxFetch derinlik sınırı
HPDFFetchAIAIntermediates, caIssuers URL'lerini aynı taşıma üzerinden dolaşır; PEM zırhını yoklar ve kuyruğu MaxFetch ile sınırlar

İmza seed değeri nedir ve neden sessizce başarısız olur?

Bir seed değeri, belge yazarının imza alanına eklediği ve imzalayana ne tür bir imzanın kabul edilebilir olduğunu söyleyen bir kısıttır: hangi SubFilter, hangi özet algoritması, hangi gerekçeler, hangi asgari PDF sürümü, yoksun bırakma bilgisinin gömülmesi gerekip gerekmediği. Alan üzerinde bir /SV sözlüğünde yaşar ve ISO 32000-1 §12.7.5.5'te tanımlanır. HotPDF onu AttachPAdESSeedValue ile yazar ve CheckLoadedSignatureSeedValue ile denetler; alan kısıtsızken ya da mevcut her kısıt geçerken True döndürür, False durumunda ise ilk başarısız kısıtı, doğrudan bir hata mesajına koyabileceğiniz bir çıkış parametresiyle adlandırır

Seed değerlerinin yanlış yapılmasını kolaylaştıran mekanizma, §12.7.5.5.3'te anlatılan /Ff bayrak girdisidir. Ayarlı bir bit, kısıtını zorunlu olarak işaretler: uyuşmazlık bir hatadır ve imzalayan reddetmelidir. Temiz bir bit, aynı kısıtı bir tercih olarak işaretler: değer, arayüzün sunacağını filtreler ve ötesi değildir. Buradan iki tuzak doğar. Birincisi, /Ff /SV sözlüğünün içinde yaşar, widget açıklamasının üzerinde değil; dolayısıyla alan düzeyindeki /Ff girdisini okuyan kod sonsuza dek boş cevap alır ve hiçbir şeyin zorlanmadığı sonucuna varır. İkincisi, bit atamaları bir, iki, dört, sekiz şeklinde basit bir dizi değildir; HotPDF'de yazıcı SubFilter için 2, MinVersion için 4, AddRevInfo için 32 ve DigestMethod için 64 yazar. Ardışık bitler varsayan bir okuyucu her kısıtı isteğe bağlı olarak çözer ve önemli olan dışındaki her testi geçer

HotPDF PAdES imzalama için seed değer bayrak biti tablosu; 2, 4, 32 ve 64 Ff bitlerini ve zorunlu ile tercih edilmiş kısıt ele alışını gösterir
/Ff girdisi /SV'nin içinde yaşar ve her bit konumu, bir uyuşmazlığın katı bir ret mi yoksa arayüz tercihi mi olduğuna karar verir
var
  Violation: AnsiString;
begin
  // İmzalayacağımız profilin bu alanda izinli olup olmadığını sorun
  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));
  // Kısıt sağlandı: imzalama geçişine devam edin
end;

Özgün kod çözme hatasını açığa çıkaran test pozitif bir test değildi. Zorlanmış bir uyuşmazlığın reddedilmesi gerektiği savıydı ve bu hata sınıfını yakalayabilen tek test türü budur: yanlış sözlüğü ya da yanlış bit konumlarını okuyan bir kod çözücü, her girdi için "hiçbir kısıt ihlal edilmedi" üretir; bilinçli olarak birini ihlal edene dek tam olarak doğru davranış gibi görünür

Bunun LTV merdivenindeki yeri

Dört basamak ve her biri altındakini gerektirir. B-B çıplak imzadır. B-T, imzalama anını sabitleyerek bir doğrulayıcının yoksun bırakmayı hangi ana karşı değerlendireceğini bilmesini sağlayan güvenilir bir zaman damgası ekler. B-LT, yoksun bırakma kanıtını DSS'e ekler; PopulatePAdESLTVEvidence bunu otomatikleştirir. B-LTA, öncekisi zayıflamadan yenilenen belge zaman damgaları ekler ve geçerliliği süresiz uzatır; HotPDF bunu RenewPAdESLTATimestamp olarak açar, yeni bir zaman damgasını artımlı bir revizyon olarak ekler ve her önceki imzayı, zaman damgasını ve DSS girdisini dokunulmamış korur

Artımlı güncelleme modeli, imzalı bir belgeye kanıt eklemenin tek doğru yoludur; çünkü dosyayı yeniden yazmak, mevcut imzaların kapsadığı bayt aralıklarını bozar. Revizyonlar arasında neyin değiştiği ve o değişikliklerin bir imzanın izin verdiği türden olup olmadığı üzerine düşünmeniz gerekiyorsa, o analiz ayrı olarak DocMDP ve FieldMDP revizyon analizinde kapsanır. İmzalama hattının kendisi, sertifika kaynakları ve bayt sırası tuzakları dahil, PAdES imzalama kılavuzunda ve doğrulama tarafı yüklenen belgelerdeki imzaların doğrulanmasında

Sıralama hakkında pratik bir uyarı. Kanıtı imzadan sonra mümkün olan en kısa sürede, ideal olarak aynı iş içinde toplayın. Bir sertifika adına yanıt verebilen yanıtlayıcılar, sertifika güncelken çevrimiçidir ve yıllar sonra gitmiştir; dolayısıyla hattınızdan B-B olarak çıkan bir belge bir daha asla yükseltilemeyebilir. HotPDF, Delphi ve C++Builder için yerel bir VCL bileşeni olarak çalışır ve tüm kanıt geçişi, sizin taşımanız dışında işlem içidir; desteklenen profiller HotPDF Delphi PDF component ürün sayfasında listelenir