Archivo del Autor: inza

Avatar de Desconocido

Acerca de inza

Presidente de EAD TRUST, Prestador Cualificado de Servicios Electrónicos de Confianza EIDAS del Grupo Garrigues. Director del Laboratorio de Identidad Digital del Observatorio Legaltech y Newlaw Garrigues - ICADE. Miembro del Grupo de Expertos ENISA Ad Hoc Working Group on EU Digital Identity Wallets Cybersecurity Certification, Presidente de la Comisión Blockchain de AMETIC. Colaboró con la DGTDAJ y el CTEAJE (Justicia) a través de Procesia. Fue Auditor Jefe en TCAB, organismo de Evaluación de Conformidad EIDAS. Pionero de la certificación digital y de la banca electrónica. Fue Vicepresidente de Mobipay (entidad de pagos móviles de BBVA), Director General de Camerfirma y de FESTE (CA de los Notarios) y Director de Redes Distribuidas en Banesto EFT y en Banesto. Fue el primer presidente de AECODI, Asociación del Sector de los Servicios de Confianza Digital.

Qualified key protection device


Since 2014, when the EIDAS, regulation was approved, we have been calling chip cards, cryptographic tokens, and HSMs (Hardware Security Module) «Qualified Signature Creation Device».

If we go back to Directive 93/1999, the name would be «Secure Signature Creation Device«.

But this is a mistake.

Qualified certificates (like other certificate types) have a field called «Key Usage» and this field indicates whether the certificate will be used for «electronic signature» (ContentCommitment) or for «authentication» (DigitalSignature), e.g. with the client authentication option of the TLS protocol.

Other uses are possible and could even be combined by activating these two, «ContentCommitment» and «DigitalSignature» simultaneously.

From the point of view of the scope of the regulation, neither the Directive 93/1999, nor the Regulation 910/2014, have expressly defined the possibility of authenticating the holder of qualified certificates. But this possibility has always been there. Although only electronic signatures (and, from the EIDAS Regulation onwards, electronic seals) have been considered, certificates that include the «DigitalSignature» bit in the «Key Usage» field are authentication certificates.

This is what was stated in the technical standard ETSI TS 102 280 and is currently stated in the technical standard ETSI EN 319 412-2.

So, if we conclude that certificates can be for authentication, and not just electronic signature, the fact that they reside on the same secure private key protection device for both uses should determine that the device should be referred to as a «Qualified Key Protection Device» and not as a «Qualified Signature Creation Device«.

By the way, I also think that the «Key Usage» bits should have different names. There was already a breakthrough when the name «Non-repudiation» became obsolete in various technical standards and was replaced by «Content Commitment», which actually means «signature» because in the signature the signatory is linked to the signed content. But the old name «Digital Signature» still persists because it technically justifies that in a challenge-response protocol, the response is calculated by performing the cryptographic operation of the digital signature on the challenge. But, in reality, this is an Authentication process and calling it a «Digital Signature» is misleading to experts and laymen alike.

The proper terms are sure «Signature» (instead of «Content Commitment») and «Authentication» (instead of «Digital Signature»), but it may be years before we see these terms in technical standards or legal rules.

Dispositivo cualificado de protección de claves


Llevamos desde 2014, fecha de aprobación de reglamento EIDAS, llamando a las tarjetas chip, a los tokens criptográficos y a los HSM (Hardware Security Module) «Dispositivo cualificado de creación de firma» .

Si nos remontamos a la Directiva 93/1999, la denominación sería «Dispositivo seguro de creación de firma«.

Pero es un error.

Los certificados cualificados (como los demás tipos de certificado) tienen un campo denominado «Key Usage» y en ese campo se indica si el certificado se usará para «firma electrónica» (ContentCommitment) o para «autenticación» (DigitalSignature), por ejemplo, con la opción de autenticación de cliente del protocolo TLS.

Además caben otros usos e, incluso, podrían combinarse, activando estos dos, «ContentCommitment» y «DigitalSignature» simultáneamente.

Desde el punto de vista del alcance de la regulación, ni la Directiva 93/1999, ni el Reglamento 910/2014, han definido de forma expresa la posibilidad de autenticar al titular de los certificados cualificados. Pero esa posibilidad siempre ha estado ahí. Aunque solo se ha considerado la firma electrónica (y, a partir del Reglamento, el sello electrónico) los certificados que incluyen activo el bit «DigitalSignature» en el campo «Key Usage» son certificados de autenticación.

Así lo recogía la norma técnica ETSI TS 102 280 y lo recoge en la actualidad la norma técnica ETSI EN 319 412-2.

Por tanto, si concluimos que los certificados pueden ser de autenticación, y no solo de firma electrónica el hecho de que residan en el mismo dispositivo seguro de protección de claves privadas tanto para un uso como para el otro, debería determinar que el dispositivo se denominara «Dispositivo cualificado de protección de claves» y no «Dispositivo cualificado de creación de firma«

Por cierto, también creo que los bits del «Key Usage» deberían tener denominaciones distintas. Ya hubo un avance cuando quedó obsoleta la denominación «Non repudiation» en diversas normas técnicas y fue sustituida por «Content Commitment«, lo que en verdad significa «firma» porque en la firma el firmante se vincula con el contenido firmado. Pero la vieja denominación «Digital Signature» todavía persiste porque justifica técnicamente que en un protocolo de reto-respuesta, la respuesta se calcula realizando la operación criptográfica de la firma digital sobre el reto. Pero, en realidad esto es un proceso de Autenticación, y llamarlo «Digital Signature» es equívoco para expertos y legos. Los términos adecuados seguramente son «Signature» (en vez de «Content Commitment«) y «Authentication» (en vez de «DigitalSignature«), pero pueden pasar años antes de que estos términos los veamos en la normas técnicas o en la legales.

Arte urbano #sudo cat system > /dev/null (y lo han vandalizado)


Hoy estoy triste porque al pasar cerca del Hospital Ramón y Cajal he visto que la pintada que registré en 2013 está parciamente borrada.

#sudo cat system > /dev/null

Esta muestra de arte urbano contiene un mensaje existencial que se enfrenta al sistema y vaticina su desaparición.

Y la metáfora utilizada es un comando Linux.

Es un tipo de arte comparable al de Banksy y con la vandalización que ha sufrido se puede comparar con las que sufrió el conocido artista.

“Girl With Balloon” de Banksy se autodestruyó en una subasta y pasó a ser «Love is in the bin»

ICALTI


De vez en cuando, aparecen retahilas de palabras que van juntas y que permiten formar siglas para designarlas y para recordarlas.

Seguramente el caso paradigmático es el de las sociedades y organismos designados por abreviaturas formadas por las iniciales de sus términos: AENA, INAP, SEDIA, DGTDAJ, IBM, NCR,…

A veces la función de recordatorio es la relevante y ciertas letras se rodean de otras que permiten formar palabas memorables.

Recuerdo de la asignatura de lógica la designación de diferentes silogismos por sus premisas y conclusiones, lo que se remonta a Aristóteles y a la filosofía griega. Barbara, Darii, Ferio, Celarent designan silosigmos AAA, AII, EIO, EAE:

  • A: premisa (o conclusión) universal afirmativa
  • E: premisa (o conclusión) universal negativa
  • I: premisa (o conclusión) particular afirmativa
  • O: premisa (o conclusión) particular negativa

Aunque quizá los términos que designaban los silogismos no resulten tan memorables en nuestros dias.

En relación con la protección de datos de la antigua LOPD, los derechos ARCO designaban los derechos de Acceso, Rectificación, Cancelación y Oposición.

Tras la publicación del RGPD (Reglamento General de Protección de Datos) los términos que permiten recordar la nueva lista de derechos han cambiado:

  • ARCOPOL: Se refiere a Acceso, Rectificación, Cancelación, Oposición, Portabilidad, Olvido (o Supresión, o Cancelación) y Limitación.
  • ARSULIPO: Acceso, Rectificación, SUpresión (Olvido), LImitación del Tratamiento, Portabilidad y Oposición
  • SOPLAR: Supresión, Oposición, Portabilidad, Limitación, Acceso y Rectificación.

Y llegamos a ICALTI.

Son los requisitos de la Contabilidad Certificada incorporados a la LGT (Ley General Tributaria) por la Ley Antifraude (Ley 11/2021, de 9 de julio, de medidas de prevención y lucha contra el fraude fiscal, de transposición de la Directiva (UE) 2016/1164, del Consejo, de 12 de julio de 2016, por la que se establecen normas contra las prácticas de elusión fiscal que inciden directamente en el funcionamiento del mercado interior, de modificación de diversas normas tributarias y en materia de regulación del juego).

Con el objetivo de no permitir la producción y tenencia de programas y sistemas informáticos que permitan la manipulación de los datos contables y de gestión, se establece la obligación de que los sistemas informáticos o electrónicos que soporten los procesos contables o de gestión empresarial se ajusten a ciertos requisitos que garanticen la integridad, conservación, accesibilidad, legibilidad, trazabilidad e inalterabilidad de los registros, requisitos cuya especificación técnica puede ser objeto de desarrollo reglamentario, el cual podría contemplar la obligación de someterlo a certificación.

En concordancia con los nuevos requisitos del software de contabilidad, facturación y gestión, se establece un régimen sancionador específico, para las empresas desarrolladoras de software y para los usuarios que lo usen (o que meramente dispongan de el) cuando no cuente con la adecuada certificación.

EADTrust ayuda a las empresas desarrolladoras de software de contabilidad, facturación y gestión a cumplir los requisitos ICALTI y puede realizar una auditoría de buenas prácticas para acreditar su cumplimiento. Contacte, llamando al 91 716 0555.

Nota sobre silogismos.

El modo del silogismo es la forma que toma el silogismo según la cantidad y la cualidad de las premisas y de la conclusión. De las 256 combinaciones posibles de los «modos» de los silogismos solo resultan válidas 19 y en el contexto de la lógica aristotélica se memorizan con los siguientes términos:

AAA, EAE, AII, EIOBARBARA, CELARENT, DARII, FERIO
EAE, AEE, EIO, AOOCESARE, CAMESTRES, FESTINO, BAROCO
AAI, IAI, AII, EAO, OAO, EIODARAPTI, DISAMIS, DATISI, FELAPTON, FERISON, BOCARDO
AAI, AEE, IAI, EAO, EIOBAMALIP, CAMENES, DIMARIS, FRESISON, FESAPO

Elecciones a vocal en la Junta Directiva de AMETIC, el 4 de noviembre de 2021


La patronal tecnológica cierra el primer período de actividad tras aplicar los nuevos estatutos y sale reforzada tras una fase compleja que ha supuesto la reinvención de la asociación.

Logo AMETIC

Transcurridos tres años desde las últimas elecciones de vocales de la Junta Directiva, y cumpliendo con los Estatutos de la Asociación, es ahora el momento de elegir los vocales de la Junta Directiva para los próximos tres años.

Según lo acordado en la Asamblea General Extraordinaria del 6 de octubre de 2021, se ha abierto la convocatoria a la Asamblea General Electoral, para el proceso de elección de los vocales de la nueva Junta Directiva, para el próximo 4 de noviembre de 2021, en la sala Jose María Cuevas de la sede de la CEOE en Madrid.

Dado que no se puede votar por correo, los asociados deberán prever la asistencia o delegar su voto.

DÍA:4 de noviembre de 2021
LUGAR:CEOE sala Jose María Cuevas
C/ Diego de León, 50 CP. 28006 Madrid
HORA:1ª Convocatoria: 10:30
2ª Convocatoria: 11:00 *La Asamblea se celebrará en 2ª convocatoria

En la web de TCAB (Trust Conformity Assessment Body) se presenta la candidatura de TCAB en las elecciones de AMETIC

Otras referencias a las elecciones de AMETIC en este blog:

Adobe actualiza su lista de confianza y sigue incluyendo la EUTL


Adobe desempeña un papel esencial en la popularización de la firma electrónica que hay que reconocer.

Por un lado, su herramienta gratuita de visualización de archivos PDF Acrobat Reader incluye sin coste una herramienta de creación de firmas electrónicas basada en certificados (entre los que destacan los certificados cualificados tal como los define el Reglamento UE 910/2014, eIdAS ).

Por otro lado, ha apostado desde la entrada en vigor del citado reglamento por incluir en la lista de confianza de sus productos (antiguamente denominada AATL) las entidades prestadoras de servicios de confianza que figuran en la lista de confianza de la unión europea (EUTL) que se puede recorrer con detalle gracias al Visualizador de Listas,

Esta combinación es importante para impulsar el uso de la firma electrónica en una herramienta que se caracteriza por la efectividad al cumplir su misión de mostrar los documentos electrónicos de forma muy parecida a los documentos en papel y establecer una potente metáfora del uso electrónico de los documentos manteniendo muchas de las ventajas de los documentos en papel, y algunas complementarias , como las informaciones adicionales que se guardan en los metadatos.

La lista actualizada de los entidades de confianza para Adobe obtenida de la EUTL puede verse en este artículo: ¿Qué es EUTL?

Y la lista concreta de los prestadores de servicios de certificación cualificados españoles (un subconjunto de la lista anterior), es esta:

Certified Digitization, what is it and what is it for?


Certified Digitization, Certified Digitisation Certified scanning, Electronic Invoice, Electronic Signature, Electronic Certificate. EIDAS, All these concepts are related.

In the development of electronic invoicing regulations, Spanish ORDER EHA / 962/2007, of April 10, which develops certain provisions on electronic billing and electronic storage of invoices, has defined in Spain the concept of Certified Digitization. This blog has been a pioneer in dealing with Certified Digitization since 2006.

Also in english, with some posts:

The homologation procedure has been included in the resolution of October 24, 2007, of the State Tax Administration Agency, on the procedure for homologation of digitization software contemplated in Order EHA / 962/2007, of April 10, 2007 .

In a strict sense, certified digitization was defined for the procedures of the tax field, which would be outside the coverage of Law 39/2015 (eGovernment). However, the implementation of the concept and the large number of available applications make it a de facto standard , also for the public sector.

Certified digitisation is the process of converting paper documents into electronic documents that contain their facsimile reproduction and are electronically signed or sealed. The systems that manage the digitisation must meet certain criteria of integrity and unalterability in the database with which the digitisation is carried out and are required to be audited. The documents digitised with this type of system have the character of originals, so that the paper documents from which they originate can be dispensed with, which is why the legal value of these processes and of the documents to which they give rise is very relevant

Certified digitisation of invoices has led to the birth of the concept that is now also used in relation to public administrations and the digitisation of Justice.

For the certified digitisation of invoices, you can use the different variants of software approved by the Tax Agency that the AEAT also publishes on its website. The provincial councils of Navarre, Biscay, Alava and Guipuzcoa have also published equivalent regulations and have approval procedures similar to those of the Spanish National Tax Agency and have their own lists of approved software.

Electronic signature

Electronic signature is regulated in the EU Regulation 910/2014, which is abbreviated as “EIDAS”.

Advanced electronic signature is uniquely linked to the signatory; allows the identification of the signatory; It is created using electronic signature creation data that the signatory can, with a high level of confidence, use under his sole control; and is llinked to the data signed therewith in such a way that any subsequent change in the data is detectable.

In summary, the advanced signature links the signatory with what was signed.

What is signed many times is condensed in the “Hash” value of the document, which is also a way to guarantee the integrity of the signed document after the advanced signature has been carried out. And the signer can be associated in various ways, with biometrics in the case of non-certificate-based signatures, or with the mathematical operation of the hash with the signer’s private key if a certificate-based signature is applied.

Certificate-based signing uses public key cryptography, also called asymmetric cryptography.

In asymmetric cryptography there are 2 keys that are mathematically linked to each other:

1. Private Key
2. Public Key

What is encrypted with the private key can only be decrypted with the public key, and vice versa.

Hash functions are unidirectional and generate a short string of characters from a document or a long string of characters.

A possible simile would be a sum value: if we transform each character in a string into a number (for example, its ASCII value) and add the values ​​of all the characters in the string, the resulting value depends on the content of the string. IF you change a character, the sum changes. The algorithms used in cryptography are more elaborate so that modifications to the strings that result in the same hash value cannot be made, which will allow the contents to be changed. Therefore, the sum value, although it serves to explain the hash, is not in itself a good hashing method.

Given a document and its «hash», it is possible to check if the hash truly corresponds to that document. However, from the hash it is not possible to deduce the document from which it came. There could be infinities. When two different documents produce the same hash value when calculating with a certain algorithm, a «collision» is said to have occurred.

How does an electronic signature work?

The document to be signed is hashed with a specific algorithm (for example, SHA-256) and the result obtained is mathematically operated with an asymmetric signature function (for example, RSA or ECC) with the private key of the signer (normally the private key resides in a chip card or a cryptographic token, and does not leave it, so the hash is sent to the chip and it is the chip that performs the cryptographic operation). The signature is made up of the result of that operation on the chip (which is sometimes called a PKCS # 1 value), and the signer’s certificate containing their data and the public key cryptographically related to the private one.

If the document and the signature are sent to the recipient (sometimes, the document format used allows the signature to be embedded inside, as is the case with PDF files). It can do the equivalent process in reverse to verify the signature.

Extracts the public key from the certificate, thereby applying the cryptographic function to the PKCS # 1 value from which the Hash value is extracted. Calculates the Hash value of the document and compares it with the value obtained from decrypting the PKCS # 1 signature. Both must be the same. If they are not the same there is a problem somewhere. For example, the document has changed in transmission or has been tampered with.

Therefore, an important effect of the electronic signature is that it guarantees the integrity and inalterability of the electronically signed documents.

The certificate used to sign is issued by a “certification authority” or a “trust service provider”. The issuance of electronic certificates is one of the possible trust services ”and, therefore, a“ certification authority ”is a“ trust service provider entity.

These entities verify the identity of the certificate applicants and after that they issue them an electronic certificate associating the public key of the certificate with a private key that must be secretly guarded by the certificate holder with maximum security.

The Electronic Certificate

The electronic certificates of a natural or legal person are electronic documents that contain information about the issuer, the period of validity of the certificate, the identity of the signer, …

The important thing is that this certificate links the public key with the identity of a specific person and that it is signed by the certification body, which has verified the applicant’s identity documents and their correspondence with the applicant’s characteristics. When the certificate is issued, its link with the private key is also established under the exclusive control of the signer.

Although unqualified certification authorities can issue certificates, in Europe qualified certification bodies, which issue qualified certificates, are preferred .

In Spain there are a significant number of qualified certificate issuing entities , among which we can mention Camerfirma, EADTrust, FNMT (CERES), Ivnosys or Vintegris.

In certain signature modalities (such as AdES – T or long-lived signatures) it is convenient to include information about the moment when the signature was created, which it does by adding a time stamp. Time stamps are issued by the Time Stamp Authority (TSA).

The timestamp shows that a certain combination of data existed before a given time and that none of this data has been modified since then.

In short, for the certified digitization of documents, an electronic certificate is needed with which to make the electronic signature on each of the scanned documents.

This requirement and the guarantee of integrity of the database in which the keeping of the invoice digitization process is managed are the most relevant to pass the audit that allows requesting the approval of the software from the AEAT.

Certified Digitization in the field of Justice.

Within the framework of the Lexnet regulations, the GIS for Certified Digitization has been defined by the CTEAJE (State Technical Committee of the Electronic Judicial Administration).

This standard allows any document to be digitized for presentation in legal proceedings, so it has a special value:

  • It is used in the private sector to digitize any document, not just invoices
  • It allows you to have digitized documents in case they are needed at any given time for a trial. This used to be the main reason for keeping paper documents: in case they were needed in court.

The requirements for certified digitization in the field of justice are very similar to those required in the tax field:

  • Electronic signature of scanned documents
  • Protection of the integrity and inalterability of the digitization record database

How do I start a certified digitization process?

To carry out the certified digitization of invoices in a company, it is necessary to have a software approved by the AEAT or by any of the foral estates of Alava, Guipuzcoa, Navarra or Vizcaya.

In order for the software to be able to carry out an electronic signature on each scanned invoice, it must be equipped with a qualified certificate. The current trend is to equip the software with a qualified legal entity certificate, in which case the resulting electronic signatures are called “qualified electronic seals” if they are managed in a device called “Qualified Seal Creation Device” (equipment that is also called HSM «Hardware Security Module»).

It is possible to carry out “certified digitization” or “guaranteed digitization” processes in the context of public administration, for which several of the Technical Interoperability Standards apply . In particular, that of authentic copy, that of digitization, that of signature policy and that of electronic document.

The ValidE portal provides some tools to validate electronic signatures and certificates. The EADTrust DSS tool also provides a lot of information about the certificates and signatures of electronic documents, whether or not they are the result of certified digitization.

Perhaps someone asked this question: is it necessary to start from the printed invoice document to be able to scan it in a certified digitization process or can an invoice received in pdf format be electronically signed?

The answer is given by ORDER EHA / 962/2007, of April 10, which develops certain provisions on telematic invoicing and electronic conservation of invoices in the different articles of which it consists.

Certified scanning can only be done from paper documents.

However, considering that the issuer and receiver can reach an agreement that the issuer of the invoice acts by sending “pre-invoices” in PDF format to the receiver and that the receiver converts them into electronic self-invoices by adding the electronic signature, the fundamental requirement of the electronic invoice, which is your electronic signature. The regulations allow invoices to be managed by the recipient (self-invoice) or a third party on behalf of the invoice issuer, who is usually the one who adds the electronic signatures or electronic stamps.

What to do if the device containing the electronic certificate is lost or stolen

In case of loss or theft of the device in which the private key associated with the electronic certificate is housed, it is necessary to request the revocation of the certificate by going to a Registration Authority of the Certification Authority that issued the certificate. Some certification authorities offer the possibility of remote revocation, using codes that were provided at the time the certificate was issued.

For example, EADTrust has a specific page and a form to request the revocation of the certificate .

Outsourcing of certified digitization processes

When a process is not focused on the core business of a company but can pose a significant administrative burden due to its volume, many entities resort to business process outsourcing (BPO).

A Certified Digitization service performed by third parties or a Remote Electronic Seal service managed by a qualified digital trust service provider can help in these cases.

Article 7 of Order EHA / 962/2007 indicates:

«This digitization process must meet the following requirements:

a) That the digitization process be carried out by the taxpayer himself or by a third party provider of digitization services , in the name and on his behalf, using in both cases software of certified digitization (…)
b) That the digitization process used guarantees the obtaining of a faithful and complete image of each digitized document and that this digital image is signed with an electronic signature in the terms of the previous articles of this Order based on an electronic certificate installed in the scanning system and invoked by the certified scanning software.This certificate must correspond to the taxpayer when the certified digitization is carried out by himself or to the digitization service provider in another case. «

Advantages of Certified Digitisation

These are some of the advantages of Certified Digitisation:

  • Saving time in the search for documents, since, as they are documents in electronic format, searches can be generated by keywords.
  • Increase the efficiency and productivity of employees by saving time in filing and searching invoicess, reducing errors.
  • Frequently digitization allows incorporating the information of the invoices in the accounting or ERP system.
  • By having digital documents managed by computer software and stored in a secure repository, decision-making is streamlined by being certain that all the information is available.
  • Saves storage space by not having to guard paper documents and saves other costs related to archival material
  • It facilitates the adoption of repetitive procedures with the environment and, indirectly, helps to pass a possible ISO 14.001 type audit

Give us a call

You can contact EADTrust by calling +34 917 160 555 if you need help to homologate a certified digitization software to be approved by Spanish Tax Agency or if you need electronic certificates to be used in Spain or Europe.

Auditoría de Contabilidad Certificada


Recientemente se ha publicado en España la denominada «Ley Antifraude» que entre los muchos aspectos que trata, incluye una sección para imponer nuevos requisitos a los sistemas y programas informáticos o electrónicos que soporten los procesos contables, de facturación o de gestión, a las empresas que los crean y a los trabajadores autónomos y empresas que los usan, con sanciones desproporcionadas que presumen la culpabilidad de las empresa y autónomos respecto a la realización de actividades de fraude tributario por el mero hecho de desarrollar o usar software «no certificado». Y los requisitos para ese software se limitan a indicar de forma ambigua que deberán aportar «integridad, conservación, accesibilidad, legibilidad, trazabilidad e inalterabilidad» (ICALTI, por sus siglas).

También se indica que «ya si eso» reglamentariamente se podrán establecer especificaciones técnicas que deban reunir dichos sistemas y programas.

Se crea una gran inseguridad jurídica ya que aunque en el régimen sancionador se indica:

e) no cumplan con las especificaciones técnicas que garanticen la integridad, conservación, accesibilidad, legibilidad, trazabilidad e inalterabilidad de los registros, así como su legibilidad por parte de los órganos competentes de la Administración Tributaria, en los términos del artículo 29.2.j) de esta Ley;

f) no se certifiquen, estando obligado a ello por disposición reglamentaria, los sistemas fabricados, producidos o comercializados.

Lo que podría dar a entender que la posibilidad de sanciones solo se podría producir tras la publicación de las «especificaciones técnicas», en el conjunto de las descripción de las sanciones no queda tan claro.

Por eso parece recomendable iniciar procesos de auditoría de contabilidad certificada a las plataformas de software de de contabilidad y facturación y a las que se instalan en terminales de punto de venta lo antes posible para demostrar «debida diligencia» en caso de que las autoridades tributarias contacten con nosotros. De esta forma, aunque no haya culminado la modificación del software para cumplir los nuevos requisitos de la norma , ya se puede demostrar que «estamos en ello».

EADTrust es una de las entidades que pueden ayudar a entender los nuevos requisitos, a implementarlos en el software y a auditarlo posteriormente para comprobar que están bien implementados.

La «Ley 11/2021, de 9 de julio, de medidas de prevención y lucha contra el fraude fiscal, de transposición de la Directiva (UE) 2016/1164, del Consejo, de 12 de julio de 2016, por la que se establecen normas contra las prácticas de elusión fiscal que inciden directamente en el funcionamiento del mercado interior, de modificación de diversas normas tributarias y en materia de regulación del juego» es la norma indicada.

El artículo decimotercero de esta Ley modifica la Ley General Tributaria en varios aspectos y en lo relativo al software de contabilidad, facturación y gestión  modifica el apartado 2 del artículo 29 para incluir los requisitos indicados. También crea un artículo 201 bis con el régimen sancionador asociado.

En el apartado 2 del artículo 29, de la Ley 58/2003, de 17 de diciembre, General Tributaria, se añade un nuevo párrafo con la letra j) que tiene la siguiente redacción:

“j) La obligación, por parte de los productores, comercializadores y usuarios, de que los sistemas y programas informáticos o electrónicos que soporten los procesos contables, de facturación o de gestión de quienes desarrollen actividades económicas, garanticen la integridad, conservación, accesibilidad, legibilidad, trazabilidad e inalterabilidad de los registros, sin interpolaciones, omisiones o alteraciones de las que no quede la debida anotación en los sistemas mismos. Reglamentariamente se podrán establecer especificaciones técnicas que deban reunir dichos sistemas y programas, así como la obligación de que los mismos estén debidamente certificados y utilicen formatos estándar para su legibilidad.”

Como se ha indicado, ese mismo artículo 13 crea un nuevo artículo 201 bis en la Ley 58/2003, de 17 de diciembre, General Tributaria:

Artículo 201 bis. Infracción tributaria por fabricación, producción, comercialización y tenencia de sistemas informáticos que no cumplan las especificaciones exigidas por la normativa aplicable.

1. Constituye infracción tributaria la fabricación, producción y comercialización de sistemas y programas informáticos o electrónicos que soporten los procesos contables, de facturación o de gestión por parte de las personas o entidades que desarrollen actividades económicas, cuando concurra cualquiera de las siguientes circunstancias:

a) permitan llevar contabilidades distintas en los términos del artículo 200.1.d) de esta Ley;

b) permitan no reflejar, total o parcialmente, la anotación de transacciones realizadas;

c) permitan registrar transacciones distintas a las anotaciones realizadas;

d) permitan alterar transacciones ya registradas incumpliendo la normativa aplicable;

e) no cumplan con las especificaciones técnicas que garanticen la integridad, conservación, accesibilidad, legibilidad, trazabilidad e inalterabilidad de los registros, así como su legibilidad por parte de los órganos competentes de la Administración Tributaria, en los términos del artículo 29.2.j) de esta Ley;

f) no se certifiquen, estando obligado a ello por disposición reglamentaria, los sistemas fabricados, producidos o comercializados.

2. Constituye infracción tributaria la tenencia de los sistemas o programas informáticos o electrónicos que no se ajusten a lo establecido en el artículo 29.2.j) de esta Ley, cuando los mismos no estén debidamente certificados teniendo que estarlo por disposición reglamentaria o cuando se hayan alterado o modificado los dispositivos certificados.

La misma persona o entidad que haya sido sancionada conforme al apartado anterior no podrá ser sancionada por lo dispuesto en este apartado.

3. Las infracciones previstas en este artículo serán graves.

4. La infracción señalada en el apartado 1 anterior se sancionará con multa pecuniaria fija de 150.000 euros, por cada ejercicio económico en el que se hayan producido ventas y por cada tipo distinto de sistema o programa informático o electrónico que sea objeto de la infracción. No obstante, las infracciones de la letra f) del apartado 1 de este artículo se sancionarán con multa pecuniaria fija de 1.000 euros por cada sistema o programa comercializado en el que se produzca la falta del certificado.

La infracción señalada en el apartado 2 anterior, se sancionará con multa pecuniaria fija de 50.000 euros por cada ejercicio, cuando se trate de la infracción por la tenencia de sistemas o programas informáticos o electrónicos que no estén debidamente certificados, teniendo que estarlo por disposición reglamentaria, o se hayan alterado o modificado los dispositivos certificados.

Por la Disposición final séptima, estas modificaciones entran en vigor transcurridos tres meses desde la entrada en vigor de la Ley, lo que se produce el 11 de octubre de 2021.

Aunque a finales de septiembre de 2021 no se han publicado formalmente especificaciones técnicas, sí que existen especificaciones semejantes para la digitalización certificada, en particular los requisitos c) y d) del apartado 1 del artículo 7 de la «Orden EHA/962/2007, de 10 de abril, por la que se desarrollan determinadas disposiciones sobre facturación telemática y conservación electrónica de facturas, contenidas en el Real Decreto 1496/2003, de 28 de noviembre, por el que se aprueba el reglamento por el que se regulan las obligaciones de facturación.«

Las entidades que conocen y se ha adaptado a las especificaciones de TIcket BAI publicadas por las Diputaciones Forales del País Vasco para el denominado «Software Garante» están un paso más cerca de poder cumplir las nuevas especificaciones, aunque tienen aspectos diferentes.

La denominación de «Contabilidad Certificada» se está empezando a usar por semejanza con la «Digitalización Certificada» que ya cuenta con requerimientos más precisos y consolidados, ya que se publicaron en 2007.

En este contexto, EADTRUST lleva a cabo procesos de consultoría y auditoría para asegurar el cumplimiento de los objetivos de la norma en los softwares de contabilidad existentes, contando con su experiencia en auditorías de Digitalización Certificada.

Tras auditar el cumplimiento de las normas en lo que se refiere a la nueva obligación de Ley 11/2021, de 9 de julio respecto a los sistemas y programas informáticos o electrónicos que soporten los procesos contables, de facturación o de gestión, EADTRUST expide un certificado de cumplimiento.

XVII Reunión Española sobre Criptología y Seguridad de la Información (RECSI) de 2022


Del 19 al 21 de octubre de 2022 se celebrará en Santander la decimoséptima edición de la Reunión Española sobre Criptología y Seguridad de la Información (RECSI), organizada por el grupo ‘Algorithmic Mathematics And Cryptography(AMAC)‘ de la Universidad de Cantabria.

La Reunión Española sobre Criptología y Seguridad de la Información (RECSI) es el congreso científico referente español en el tema de la Seguridad en las Tecnologías de la Información y Comunicación, donde se dan cita de forma aproximadamente bienal los principales investigadores españoles en el tema, así como invitados extranjeros de reconocido prestigio. En estos encuentros se muestran los avances de los grupos de investigación que presentan comunicaciones y fomentan la participación de los jóvenes investigadores.

Las anteriores ediciones tuvieron lugar en

  • Palma de Mallorca (1991),
  • Madrid (1992),
  • Barcelona (1994),
  • Valladolid (1996),
  • Torremolinos (1998),
  • Santa Cruz de Tenerife (2000),
  • Oviedo (2002),
  • Leganés (2004),
  • Barcelona (2006), 
  • Salamanca (2008), 
  • Tarragona (2010), 
  • San Sebastián (2012), 
  • Alicante(2014), 
  • Maó (2016), 
  • Granada (2018) y 
  • Lleida (2021).

Para participar en el Congreso, los ponentes debente tener en cuenta las siguientes fechas:

  • Envio de trabajos: hasta el 28 de abril del 2022.
  • Notificación autores: 10 de junio del 2022.
  • Trabajos definitivos: hasta 15 de Julio del 2022
  • Inscripción: hasta 30 de julio del 2022.

Más información en la web del Congreso XVII RECSI.

Los certificados DSC de España con los que se firman los pasaportes COVID


Algunos paises europeos han publicado la información de los certificados electrónicos ECC (y unos pocos RSA) con los que se firman los pasaportes COVID (oficialmente «Certificados Digitales COVID» y anteriormente «Certificados verdes digitales»). Estos certificados se denominan DSC (Document Signing Certificate). Ya lo mencioné en el artículo «Public Key of Spain CSCA for European digital COVID certificate«.

Uno de los países que publican la información de dichos certificados electrónicos es Suecia, que hace referencia a los certificados incluidos en la pasarela de validación de confianza de pasaportes COVID (Técnicamente «Digital Green Certificate Gateway» DGCG).

En España, todos los certificados menos uno los ha expedido EADTrust (European Agency of Digital Trust), por lo que la Sub-CA de certificados de curva elíptica P-256 para sello de órgano de EADTrust se ha convertido en la principal CSCA (Certificate Signing Certificate Authority de España. Otra singularidad del sistema adoptado en España es que los DSC emitidos por EADTrust son, además, certificados cualificados de sello de órgano según el Reglamento EIDAS.

Estos son los datos principales de certificados de CSCA y DSC de España:

Country: ES
TypeNameContactPurpose
CSCA CertificateOU=Legal Person, OID.2.5.4.97=VATES-B85626240, C=ES, O=»European Agency of Digital Trust, S.L.», CN=EADTrust ECC 256 SubCA For Qualified Certificates 2019ca@eadtrust.eu
CSCA CertificateCN=iCA Izenpe, OU=Peer, O=IZENPE S.A., C=ES
Document SignerC=ES, O=SERVICIO DE SALUD DE LAS ISLAS BALEARES, OID.2.5.4.97=VATES-Q0719003F, OU=SELLO ELECTRONICO, SERIALNUMBER=Q0719003F, CN=IBSALUT-CVD-SELLO1.3.6.1.5.5.7.3.2, 1.3.6.1.5.5.7.3.4
Document SignerC=ES, O=Servicio Extremeño de Salud, OID.2.5.4.97=VATES-Q0600413I, OU=SSII, OU=SELLO ELECTRONICO, SERIALNUMBER=Q0600413I, CN=Servicio Extremeño de Salud1.3.6.1.5.5.7.3.2, 1.3.6.1.5.5.7.3.4
Document SignerC=ES, O=GERENCIA REGIONAL DE SALUD DE CASTILLA Y LEON, OID.2.5.4.97=VATES- Q4700608E, OU=GERENCIA REGIONAL DE SALUD DE CASTILLA Y LEON, OU=SELLO ELECTRONICO, SERIALNUMBER=Q4700608E, CN=GERENCIA REGIONAL DE SALUD CASTILLA Y LEÓN (SACYL)1.3.6.1.5.5.7.3.2, 1.3.6.1.5.5.7.3.4
Document SignerC=ES, O=»DIRECCION GENERAL DE SALUD PUBLICA, CONSUMO Y CUIDADOS», OID.2.5.4.97=VATES-S2633001I, OU=»DIRECCIÓN GENERAL DE SALUD PUBLICA, CONSUMO Y CUIDADOS», OU=SELLO ELECTRONICO, SERIALNUMBER=S2633001I, CN=Gobierno de La Rioja1.3.6.1.5.5.7.3.2, 1.3.6.1.5.5.7.3.4
Document SignerC=ES, O=Servicio Canario de la Salud, OID.2.5.4.97=VATES-Q8555011I, OU=Secretaría General del Servicio Canario de la Salud, OU=SELLO ELECTRONICO, SERIALNUMBER=Q8555011I, CN=Secretaría General del Servicio Canario de la Salud1.3.6.1.5.5.7.3.2, 1.3.6.1.5.5.7.3.4
Document SignerC=ES, O=CIUDAD AUTÓNOMA DE MELILLA, OID.2.5.4.97=VATES-S7900010E, OU=DIRECCIÓN GENERAL DE LA SOCIEDAD DE LA INFORMACIÓN, OU=SELLO ELECTRONICO, SERIALNUMBER=S7900010E, CN=SELLO ELECTRONICO DE LA CIUDAD AUTÓNOMA DE MELILLA1.3.6.1.5.5.7.3.2, 1.3.6.1.5.5.7.3.4
Document SignerC=ES, O=SERVICIO ANDALUZ DE SALUD, OID.2.5.4.97=VATES-Q9150013B, OU=SERVICIO ANDALUZ DE SALUD, OU=SELLO ELECTRONICO, SERIALNUMBER=Q9150013B, CN=SELLO SAS PARA CERTIFICADO COVID DE LA UE1.3.6.1.5.5.7.3.2, 1.3.6.1.5.5.7.3.4
Document SignerCN=DIRECCIÓN DE SALUD PÚBLICA Y ADICCIONES, OID.2.5.4.97=VATES-S4833001C, OU=SELLO ELECTRONICO, O=EUSKO JAURLARITZA – GOBIERNO VASCO, C=ES1.3.6.1.5.5.7.3.2
Document SignerC=ES, O=Servicio Cántabro de Salud, OID.2.5.4.97=VATES-Q3900738J, OU=SELLO ELECTRONICO, SERIALNUMBER=Q3900738J, CN=Servicio Cántabro de Salud1.3.6.1.5.5.7.3.2, 1.3.6.1.5.5.7.3.4
Document SignerC=ES, O=Servicio de Salud de Castilla-La Mancha, OID.2.5.4.97=VATES- Q4500146H, OU=SELLO ELECTRONICO, SERIALNUMBER=Q4500146H, CN=SESCAM Certificado Digital COVID UE1.3.6.1.5.5.7.3.2, 1.3.6.1.5.5.7.3.4
Document SignerC=ES, O=Ministerio de Defensa, OID.2.5.4.97=VATES-S2830001J, OU=Inspección General de Sanidad de la Defensa, OU=SELLO ELECTRONICO, SERIALNUMBER=S2830001J, CN=Inspección General de Sanidad de la Defensa1.3.6.1.5.5.7.3.2, 1.3.6.1.5.5.7.3.4
Document SignerC=ES, O=Principado de Asturias, OID.2.5.4.97=VATES- S3333001J, OU=SELLO ELECTRONICO, SERIALNUMBER=S3333001J, CN=Consejería de Salud del Principado de Asturias1.3.6.1.5.5.7.3.2, 1.3.6.1.5.5.7.3.4
Document SignerC=ES, O=Servicio Navarro de Salud-Osasunbidea, OID.2.5.4.97=VATES-Q3150004D, OU=Servicio Navarro de Salud-Osasunbidea, OU=SELLO ELECTRONICO, SERIALNUMBER=Q3150004D, CN=Sello Electrónico del Servicio Navarro de Salud-Osasunbidea1.3.6.1.5.5.7.3.2, 1.3.6.1.5.5.7.3.4
Document SignerC=ES, O=CIUDAD AUTONOMA DE CEUTA, OID.2.5.4.97=VATES-S6100007A, OU=CIUDAD AUTONOMA DE CEUTA, OU=SELLO ELECTRONICO, SERIALNUMBER=S6100007A, CN=CEUTA1.3.6.1.5.5.7.3.2, 1.3.6.1.5.5.7.3.4
Document SignerC=ES, O=GENERALITAT VALENCIANA, OID.2.5.4.97=VATES-S4611001A, OU=CONSELLERIA DE SANITAT UNIVERSAL I SALUT PÚBLICA, OU=SELLO ELECTRONICO, SERIALNUMBER=S4611001A, CN=GENERALITAT VALENCIANA1.3.6.1.5.5.7.3.2, 1.3.6.1.5.5.7.3.4
Document SignerC=ES, O=Departament de Salut de la Generalitat de Catalunya, OID.2.5.4.97=VATES-S0811001G, OU=Departament de Salut, OU=SELLO ELECTRONICO, SERIALNUMBER=S0811001G, CN=CERT-GENCAT-1S-211.3.6.1.5.5.7.3.2, 1.3.6.1.5.5.7.3.4
Document SignerC=ES, O=COMUNIDAD AUTONOMA DE LA REGION DE MURCIA, OID.2.5.4.97=VATES- S3011001l, OU=DIRECCION GENERAL INFORMATICA CORPORATIVA, OU=SELLO ELECTRONICO, SERIALNUMBER=S3011001l, CN=DIRECCIÓN GENERAL DE SALUD PÚBLICA Y ADICCIONES1.3.6.1.5.5.7.3.2, 1.3.6.1.5.5.7.3.4
Document SignerC=ES, O=MINISTERIO DE SANIDAD, OID.2.5.4.97=VATES-S2827001E, OU=SELLO MINISTERIO DE SANIDAD CERTIFICACION COVID19, OU=SELLO ELECTRONICO, SERIALNUMBER=S2827001E, CN=SELLO MINISTERIO DE SANIDAD CERTIFICACION COVID191.3.6.1.5.5.7.3.2, 1.3.6.1.5.5.7.3.4
Document SignerC=ES, O=GOBIERNO DE ARAGON, OID.2.5.4.97=VATES-S5011001D, OU=DEPARTAMENTO DE SANIDAD, OU=SELLO ELECTRONICO, SERIALNUMBER=S5011001D, CN=DEPARTAMENTO DE SANIDAD DEL GOBIERNO DE ARAGON1.3.6.1.5.5.7.3.2, 1.3.6.1.5.5.7.3.4
Document SignerC=ES, O=SERVICIO MADRILEÑO DE SALUD, OID.2.5.4.97=VATES-Q2801221I, OU=DG SISTEMAS DE INFORMACION Y EQUIPAMIENTOS SANITARIOS, OU=SELLO ELECTRONICO, SERIALNUMBER=Q2801221I, CN=FIRMA CERTIFICADO COVID DIGITAL UE 11.3.6.1.5.5.7.3.2, 1.3.6.1.5.5.7.3.4
Document SignerC=ES, O=Consellería de Sanidad, OID.2.5.4.97=VATES-S1511001H, OU=SELLO ELECTRONICO, SERIALNUMBER=S1511001H, CN=ConselleriadeSanidade.XuntadeGalicia1.3.6.1.5.5.7.3.2, 1.3.6.1.5.5.7.3.4