Ley antifraude 2021 (VERIFACTU) - Programas informáticos

[antoine0]

Empezado por sglorka

Este requisito está imponiendo a los sistemas que controlen sus datos anteriores para asegurarse que no hay fraude.

Se entiende que, una vez generados los registros, de alguna manera, tenemos que garantizar que fueron los originales que se crearon en un primer momento. No confundir esto con la adición de huellas hash o firmado electrónico de los registros para garantizar que no han sido modificados (que también hay que cumplir).

Pero sí puedes usar huellas para cumplirlo. Y creo que te incentivan a esto...

Tenemos que demostrar que esos registros fueron los originales que se generaron en un primer momento

No creo que vaya a tanto. Tienes que poder detectar si hay un registro alterado, y en tal caso avisar.
Nota también que un sistema puede cumplir avisando si hay meras sospechas de alteración, aunque los registros son los originales, solo si pasa algo que no le cuadra al programa.
Otra cosa: hay casos que precisan de ensanchar los registros del sistema de facturación. El sistema debe continuar a cumplir aunque necesariamente los registros ya no son los originales (que eran más estrechos).

[...] ya que podemos generar una serie de registros simulados a posteriori alterando las fechas de creación de los registros mediante utilizades archiconocidas y manteniendo su encadenamiento y huellas hash. Estos registros simulados son tan válidos como los originales.

Si cambias algún dato en un registro, siga una fecha o cualquier otra cosa, la huella SHA256 del registro no será la misma; si los registros están encadenados —es decir, la huella del precedente es parte de los datos del registro— cambiar la huella SHA256 de uno cambia todas los siguientes huellas; incluyendo entonces el último registro.

Por tanto, si al generar o validar un registro compruebas que la huella del precedente (él que era el último) no coincide con la esperada, sabes que hay alguna alteración, y debes señalarla.

Y ocurre que en su gran sabiduría, AEAT nos pide guardar dicha huella dentro del nuevo registro...

Entiendo que deberíamos generar una clave hash de todo el fichero y almacenarla en una tabla donde se registre cada registro de facturación emitido. De esta manera, podemos comparar el hash del archivo de registro de facturación con el hash que tenemos en nuestra tabla de registros

Me parece una manera complicada de cumplir con la normativa. Mi archivo actual de facturación pesa más de 500 MiB, no me veo calculando la huella SHA256 a cada vez que quiero generar un nuevo registro. Además, un fichero de base de datos tiene habitualmente bytes de relleno sin usar que puedan cambiar de valor sin alterar los registros en sí (aunque esto sí puede ser un ejemplo de lo que he escrito arriba sobre las sospechas).

[sglorka]

Empezado por antoine0

Este requisito está imponiendo a los sistemas que controlen sus datos anteriores para asegurarse que no hay fraude.


Pero sí puedes usar huellas para cumplirlo. Y creo que te incentivan a esto...


No creo que vaya a tanto. Tienes que poder detectar si hay un registro alterado, y en tal caso avisar.
Nota también que un sistema puede cumplir avisando si hay meras sospechas de alteración, aunque los registros son los originales, solo si pasa algo que no le cuadra al programa.
Otra cosa: hay casos que precisan de ensanchar los registros del sistema de facturación. El sistema debe continuar a cumplir aunque necesariamente los registros ya no son los originales (que eran más estrechos).



Si cambias algún dato en un registro, siga una fecha o cualquier otra cosa, la huella SHA256 del registro no será la misma; si los registros están encadenados —es decir, la huella del precedente es parte de los datos del registro— cambiar la huella SHA256 de uno cambia todas los siguientes huellas; incluyendo entonces el último registro.

Por tanto, si al generar o validar un registro compruebas que la huella del precedente (él que era el último) no coincide con la esperada, sabes que hay alguna alteración, y debes señalarla.

Y ocurre que en su gran sabiduría, AEAT nos pide guardar dicha huella dentro del nuevo registro...


Me parece una manera complicada de cumplir con la normativa. Mi archivo actual de facturación pesa más de 500 MiB, no me veo calculando la huella SHA256 a cada vez que quiero generar un nuevo registro. Además, un fichero de base de datos tiene habitualmente bytes de relleno sin usar que puedan cambiar de valor sin alterar los registros en sí (aunque esto sí puede ser un ejemplo de lo que he escrito arriba sobre las sospechas).

Quizás no me expliqué correctamente antoine0. Yo me he puesto en la situación más extrema. Imagina que diariamente voy generando los registros de facturación encadenados y correctamente fechados. Si no los envío de forma automática si no que los almaceno hasta que me los requiera la aeat yo puedo volver a generar esos registros con otra realidad diferente y su encadenamiento y fechado bien definido utilizando programas que permiten el cambio en la fecha de creación del fichero y por ende, mi nueva colección de registros de facturación será correcta. Por eso, para cumplir con el el apartado a). La integridad e inalterabilidad de los registros de facturación de forma que, una vez generados y registrados, no puedan ser alterados sin que el sistema informático lo detecte y avise de ello.
me imagino que deberíamos hacer algo más para certificar que esos registros fueron los creados originalmente.

[ermendalenda]

https://sede.agenciatributaria.gob.e...ri_factu_.html

[[newtron]]

Empezado por ermendalenda

https://sede.agenciatributaria.gob.e...ri_factu_.html

¿Dónde pone que todavía no ha empezado el tiempo a contar?

Edito:

Vaaaaaaaaaaaaaaaaaaale... ha sido enviar el mensaje y ya lo he visto:

"A este real decreto le seguirá la orden ministerial de desarrollo técnico, a partir de la cual los desarrolladores de programas informáticos deberán someterse a sus disposiciones en un plazo máximo de 9 meses."

O sea, que hasta no publiquen el desarrollo técnico no empieza el plazo. Vale.

Y ya puestos pregunto: También dicen que la gente puede usar el Kit Digital para estas modificaciones y yo tenía entendido que el Kit Digital no financia modificaciones de programas, solo nuevas soluciones y con unos requerimientos casi imposibles de cumplir. ¿Alguien sabe algo de esto?

Saludos.

[rkinformatika]

Empezado por newtron

¿Dónde pone que todavía no ha empezado el tiempo a contar?

Edito:

Vaaaaaaaaaaaaaaaaaaale... ha sido enviar el mensaje y ya lo he visto:

"A este real decreto le seguirá la orden ministerial de desarrollo técnico, a partir de la cual los desarrolladores de programas informáticos deberán someterse a sus disposiciones en un plazo máximo de 9 meses."

O sea, que hasta no publiquen el desarrollo técnico no empieza el plazo. Vale.

Y ya puestos pregunto: También dicen que la gente puede usar el Kit Digital para estas modificaciones y yo tenía entendido que el Kit Digital no financia modificaciones de programas, solo nuevas soluciones y con unos requerimientos casi imposibles de cumplir. ¿Alguien sabe algo de esto?

Saludos.

Buenas,

Los requerimientos para la solución de Facturación Electronica del Kit Digital para los segmentos II y III estan adaptados para Veri*Factu. De hecho, los requerimientos son compatibles con TicketBAI y nosotros hemos justificado y financiado con los fondos del Kit Digital cientos de clientes que usan nuestro software de TicketBAI. Las evidencias que piden son, entre otras cosas, la posibilidad de la verificación de la factura (QR), REGISTRO DE FACTURACIÓN,(integridad, conservación, accesibilidad, legibilidad, trazabilidad, e inalterabilidad de los datos), una declaración responsable etc...

Cruzamos dedos que quedan fondos para adaptar a todas las empresas y autonomos de españa ;-)

[[newtron]]

Empezado por rkinformatika

Buenas,

Los requerimientos para la solución de Facturación Electronica del Kit Digital para los segmentos II y III estan adaptados para Veri*Factu. De hecho, los requerimientos son compatibles con TicketBAI y nosotros hemos justificado y financiado con los fondos del Kit Digital cientos de clientes que usan nuestro software de TicketBAI. Las evidencias que piden son, entre otras cosas, la posibilidad de la verificación de la factura (QR), REGISTRO DE FACTURACIÓN,(integridad, conservación, accesibilidad, legibilidad, trazabilidad, e inalterabilidad de los datos), una declaración responsable etc...

Cruzamos dedos que quedan fondos para adaptar a todas las empresas y autonomos de españa ;-)

Gracias por tu respuesta pero (corrígeme si estoy equivocado). ¿No piden que el programa tenga API? ¿por ejemplo? Aparte de que quiero recordar que dice expresamente que no financia modificaciones a lo que hay, tendría que rebuscar en la normativa pero creo que lo he leido en alguna parte.


¿Tú en las justificaciones de software no has tenido que informar del tema API?



Saludos.

[rkinformatika]

Empezado por newtron

Gracias por tu respuesta pero (corrígeme si estoy equivocado). ¿No piden que el programa tenga API? ¿por ejemplo? Aparte de que quiero recordar que dice expresamente que no financia modificaciones a lo que hay, tendría que rebuscar en la normativa pero creo que lo he leido en alguna parte.


¿Tú en las justificaciones de software no has tenido que informar del tema API?



Saludos.

Apartado 8.INTEGRACIÓN CON OTRAS SOLUCIONES,

Adjuntar, a continuación, las capturas de pantalla en
las que se muestren, por ejemplo, la funcionalidad
de integración y las opciones de integración que
ofrece.

Mostramos la integración con Hacienda y mas cosas.

[antoine0]

Empezado por sglorka

Por eso, para cumplir con el el apartado a). La integridad e inalterabilidad de los registros de facturación de forma que, una vez generados y registrados, no puedan ser alterados sin que el sistema informático lo detecte y avise de ello. me imagino que deberíamos hacer algo más para certificar que esos registros fueron los creados originalmente.

Yo creo que no (aparte de los logs de eventos del 8.3, que están por definir con más detalle en la O.M.)
Pero se puede discutir.

[Neftali [Germán.Estévez]]

Empezado por sglorka

Imagina que diariamente voy generando los registros de facturación encadenados y correctamente fechados. Si no los envío de forma automática si no que los almaceno hasta que me los requiera la aeat yo puedo volver a generar esos registros con otra realidad diferente y su encadenamiento y fechado bien definido utilizando programas que permiten el cambio en la fecha de creación del fichero y por ende, mi nueva colección de registros de facturación será correcta.

Creo que no es posible, porque te olvidas de que cuando le entregas o le envías la factura/ticket al cliente, esa factura incluye el código QR (que para eso obligan a ponerlo).
Ese código QR lleva información del firmado de la factura y del encadenamiento.

Si vuelves a generar como tú dices y "regeneras" toda esa información, no coincidirá con lo que tiene el cliente.
Por eso una vez enviada/impresa ya no se puede modificar.

Imagino que si generas 2 facturas, no las envías al cliente (es decir, no han salido de tu sistema), esas 2 últimas facturas podrías borrarlas y volver a generarlas (y sus encadenamientos), pero en cuando el cliente tiene una copia, eso ya no es posible (al menos de esa factura y las anteriores).

[sglorka]

Empezado por Neftali [Germán.Estévez]

Creo que no es posible, porque te olvidas de que cuando le entregas o le envías la factura/ticket al cliente, esa factura incluye el código QR (que para eso obligan a ponerlo).
Ese código QR lleva información del firmado de la factura y del encadenamiento.

Si vuelves a generar como tú dices y "regeneras" toda esa información, no coincidirá con lo que tiene el cliente.
Por eso una vez enviada/impresa ya no se puede modificar.

Imagino que si generas 2 facturas, no las envías al cliente (es decir, no han salido de tu sistema), esas 2 últimas facturas podrías borrarlas y volver a generarlas (y sus encadenamientos), pero en cuando el cliente tiene una copia, eso ya no es posible (al menos de esa factura y las anteriores).

Bueno yo me pongo como abogado del diablo. Seguro que te pillan si se hacen con una copia de factura emitida a un cliente, pero no es eso lo que me preocupa. Lo que intento averiguar es cómo garantizar lo que pide el apartado a), justificar que los registros que hemos generado son los originales con algún método técnico fiable, cito dicho apartado

La integridad e inalterabilidad de los datos registrados se asegurará utilizando
cualquier proceso técnico fiable que garantice el carácter fidedigno y completo de los
registros de facturación desde que hayan sido grabados en el sistema informático

[Neftali [Germán.Estévez]]

Empezado por sglorka

... Lo que intento averiguar es cómo garantizar lo que pide el apartado a), justificar que los registros que hemos generado son los originales con algún método técnico fiable, cito dicho apartado

La integridad e inalterabilidad de los datos registrados se asegurará utilizando
cualquier proceso técnico fiable que garantice el carácter fidedigno y completo de los
registros de facturación desde que hayan sido grabados en el sistema informático

Entiendo que están pidiendo que tu sistema informático implemente "algún sistema" para no permitir modificar una factura que ya se ha generado (entendiendo por "generada" cuando ya la tiene el cliente)o la has enviado si tienes VERI*FACTU (ese momento se puede discutir*).

A partir de ese momento (*) no se puede modificar y tu sistema debe implementar "algo" para asegurarlo. El qué ya será cosa de cada uno.

• Una marca en la factura (check)
• Regenerar el XML y comprobar que no ha cambiado
• Ponerla en sólo-lectura
• ...

[nuevo1234]

Empezado por Neftali [Germán.Estévez]

Entiendo que están pidiendo que tu sistema informático implemente "algún sistema" para no permitir modificar una factura que ya se ha generado (entendiendo por "generada" cuando ya la tiene el cliente)o la has enviado si tienes VERI*FACTU (ese momento se puede discutir*).

A partir de ese momento (*) no se puede modificar y tu sistema debe implementar "algo" para asegurarlo. El qué ya será cosa de cada uno.

• Una marca en la factura (check)
• Regenerar el XML y comprobar que no ha cambiado
• Ponerla en sólo-lectura
• ...

Cuando se guardan deben ir firmados. Entiendo q la firma ya garantiza q no se modifica después. Vendrá el día y la hora en la firma o algo asi

[Neftali [Germán.Estévez]]

Empezado por nuevo1234

Cuando se guardan deben ir firmados. Entiendo q la firma ya garantiza q no se modifica después. Vendrá el día y la hora en la firma o algo asi

La firma no garantiza que no se modifique, la firma garantiza que si se modifica, se pueda detectar.
Tu sistema deberá implementar algo" para que el usuario final no pueda modificar una factura ya "generada". A eso creo que es a lo que se refiere ese párrafo.

[antoine0]

Empezado por nuevo1234

Cuando se guardan deben ir firmados. Entiendo q la firma ya garantiza q no se modifica después. Vendrá el día y la hora en la firma o algo asi

Una firma solo garantiza que el firmante (él que tiene la clave privada del certificado de firma) tenía a mano los datos firmados.
Si después de la (primera) firma, los datos se modifican fuera del poder del firmante, entonces la firma resultará inválida; pero técnicamente los datos modificados se pueden supuestamente firmar de nuevo (nota: es delito hacerlo; también es delito proponer de hacerlo) si lo hace el firmante...

El día o la hora no vienen en la firma; solo se puede añadir una marca (o sello) de tiempo a lo que se está firmando.

Si usas Veri*factu, la firma la realiza efectivamente Hacienda y sus sistema dan la hora y por tanto Hacienda tiene la garantía que los datos no se modifican en el momento de la generación.
Si es otra clase de SIF, el programador puede añadir una marca de tiempo a la hora de firmar; así sí se garantiza que no se modifican después (a no ser que se manipulen las marcas de tiempo; otro probable delito). Pero la marca de tiempo no es una obligación en lo que sabemos ahora de las especificaciones, entre otras cosas porque no hay un sistema de marca de tiempo disponible que resulte de agradecimiento tanto de Hacienda como de todos los grandes productores de software.