[bezpieczeństwo] - Możliwa podatność SSotSS przy uwierzytenieniu XAdES

[sosoba]

Specyfikacja ETSI TS 101 903 - Technical Specification Electronic Signatures and Infrastructures XML Advanced Electronic Signatures (XAdES)
w rodziale 4.4.1 Basic electronic signature (XAdES-BES) wyraźnie specyfikuje, że podpis zgodny z nawet podstawowym profilem XAdES-BES MUSI zawierać co najmniej jeden z następujących elementów walidowanych przez odbiorcę dokumentu:

• SigningCertificate (w SignedProperties)
• lub Reference w SignedInfo podpisujący element KeyInfo

Brak któregoś z tych rozwiązań wprowadza krytyczną podatność polegającą na braku możliwości udowodnienia przez odbiorcę który certyfikat został wykorzystany do złożenia podpisu (simple substitution of the signer's certificate) opisaną w rodziale 7.2.2 specyfikacj.

Testy wykazały, że obecnie metoda /auth/xades-signature zarówno środowiska testowego jak i demonstracyjnego (a więc zapewne i produkcyjnego) pozwala na przekazanie dokumentu pozbawionego tych zabezpieczeń tj. z pustym SignedProperties oraz SignedInfo nie obejmującym KeyInfo np.

<Signature xmlns="http://www.w3.org/2000/09/xmldsig#">
  <SignedInfo xmlns="http://www.w3.org/2000/09/xmldsig#">
    <SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#ecdsa-sha256"></SignatureMethod>
    <Reference Type="http://www.w3.org/2000/09/xmldsig#Object" URI="#data">...</Reference>
    <Reference Type="http://uri.etsi.org/01903#SignedProperties" URI="#sp">...</Reference>
  </SignedInfo>
  <SignatureValue>...</SignatureValue>
  <KeyInfo><X509Data><X509Certificate>...</X509Certificate></X509Data></KeyInfo>
  <Object>
    <QualifyingProperties xmlns="http://uri.etsi.org/01903/v1.3.2#" Target="#qp">
      <SignedProperties xmlns="http://uri.etsi.org/01903/v1.3.2#" xmlns:ds="http://www.w3.org/2000/09/xmldsig#" Id="sp"></SignedProperties>
    </QualifyingProperties>
  </Object>
  <Object xmlns="http://www.w3.org/2000/09/xmldsig#" Id="data">
    <AuthTokenRequest xmlns="http://ksef.mf.gov.pl/auth/token/2.0">
      <Challenge>20260201-CR-...</Challenge>
      <ContextIdentifier><Nip>...</Nip></ContextIdentifier>
      <SubjectIdentifierType>certificateSubject</SubjectIdentifierType>
    </AuthTokenRequest>
  </Object>
</Signature>

W określonych scenariuszach (których z powodów oczywistych nie będę podpowiadał) luka ta doprowadza do sytuacji w której MF nie będzie w stanie udowodnić kto podpisał dokument autoryzacji.

Uprzejmie sugeruję wykonanie audytu tej części rozwiązania i ewentualne zablokowanie możliwości autentykacji podpisem XAdES do czasu naprawy.

[k-wysocki-bl]

Dzięki. Sprawdzamy.