Seguridad de la billetera: la falacia de la "no custodia"

La expresión comúnmente citada "no sus claves, no su criptografía" transmite la filosofía purista de la gestión de claves criptográficas. En este modelo de seguridad de billetera, solo un individuo (o un grupo a través de "multisig") tiene control directo y exclusivo sobre sus propias claves privadas y, por lo tanto, tiene la verdadera propiedad de sus criptoactivos. Las billeteras criptográficas que se adhieren a este enfoque de línea dura se denominan "sin custodia", lo que significa que ninguna parte externa tiene acceso a las claves.

Excepto, no tan rápido. La situación no es tan simple. Una serie de hacks de billetera "sin custodia" de alto perfil, incluido el Truco de billetera Slope que comprometió más de 8,000 cuentas en agosto, el Truco de billetera Trinity que perdió más de $ 2 millones en tokens IOTA en 2020, el Hack de billetera de paridad que permitió a un atacante robar 150,000 ETH en 2017, además de descubrimientos de varios vulnerabilidades de la billetera de hardware, y otros incidentes, socava la distinción convencional entre billeteras con custodia y sin custodia. En muchos de estos casos, las víctimas que creían que estaban usando una billetera sin custodia descubrieron que los atacantes podían secuestrar sus claves codiciadas. Una contradicción, ¿no?

De hecho, la historia es más compleja de lo que puede captar un eslogan. Las billeteras sin custodia realmente no dan a los usuarios el control total de sus claves. Eso es porque las billeteras son típicamente creado por, y operado a través de, software o hardware de otra persona. Los usuarios depositan constantemente su confianza en otras personas, productos y programas informáticos. Aceptan el uso de interfaces de línea de comandos de blockchain, software y dispositivos de billetera, plataformas centralizadas, código de contrato inteligente, aplicaciones descentralizadas y todas las diversas billeteras integraciones de conexión en el medio. Cada punto de contacto agrega riesgo; la suma de todas estas partes entrelazadas hace añicos la ilusión de la billetera sin custodia.

La tutela es, en realidad, no–binario. Lo que a primera vista podría parecer no privativo de la libertad, en realidad puede implicar muchos elementos de custodia cuya fiabilidad la gente a menudo da por sentada. La dicotomía tradicional –custodia vs. no custodial– es falsa. 

En cambio, es mejor considerar las billeteras con más matices. Las preguntas clave que debe hacerse son: ¿Qué superficie de ataque me siento cómodo aceptando y cuántas responsabilidades estoy dispuesto a asumir en mi búsqueda para eliminar la confianza en terceros? En general, la administración de claves, la base de la seguridad de la billetera, se puede dividir en tres áreas, cada una de las cuales tiene oportunidades únicas de exposición. Las subcategorías son las siguientes:

1. Generación clave (creando claves criptográficas)

2. Almacenamiento de claves (asegurando llaves en reposo)

3. Uso de claves (poniendo las llaves a trabajar)

Esta descripción general tiene como objetivo ayudar a los usuarios de web3 a comprender mejor las complejidades involucradas en la protección de sus activos a través de la rúbrica anterior. Además, nuestro objetivo es ayudar a los ingenieros a identificar y reforzar los puntos de falla frecuentes en el desarrollo de billeteras. Esperamos que la aplicación de esta guía, que proviene de nuestros muchos años de experiencia combinada en la creación de sistemas criptográficos y de seguridad en Docker, Anchorage, Facebook y a16z crypto, ayudará a las personas a evitar contratiempos de seguridad, ya sea que interactúen, participen o construyendo tecnología web3.

A continuación, cubrimos las características comunes y las trampas de las plataformas de seguridad y custodia de billeteras criptográficas tal como existen en la actualidad. También cubrimos áreas que creemos que requieren la mayor atención y desarrollo en los próximos meses y años para mejorar la seguridad de las experiencias web3 de los usuarios.

Seguridad de billetera de generación de claves

Cualquier discusión sobre la seguridad de la billetera debe comenzar con la generación de claves, el proceso de creación de claves criptográficas. Ya sea que la billetera se considere con o sin custodia, las propiedades de seguridad del paso de generación de claves son primordiales para la seguridad de las claves a partir de entonces. Durante la generación de claves, hay tres preocupaciones generales a tener en cuenta: usar código confiable, implementar el código correctamente y manejar la salida de manera segura.

Si no es un experto en criptografía, puede ser difícil verificar que todos los siguientes factores se realicen en el libro. Verifique si puede acceder a un informe de auditoría confiable, que algunos proveedores de billeteras publican en sus sitios web oficiales o repositorios de Github. En lugar de eso, haga su propia investigación para tratar de determinar si hay una empresa de confianza detrás de la billetera. Si la información es escasa, la actividad significativa de usuarios y desarrolladores podría ser el siguiente indicador de reputación.

Siga estas pautas para reducir su exposición al riesgo. Si una billetera falla en los siguientes controles, ¡huye!

• Use billeteras que no generen su propia criptografía

Los criptógrafos tienen un dicho: "no hagas tu propia criptografía". La esencia es similar al adagio "no reinventar la rueda". La rueda está bien como está y es probable que cualquier intento de reconstruir una desde cero resulte en un producto peor. Lo mismo ocurre con la criptografía, una ciencia que es difícil de entender correctamente. El código que compone una billetera debe tener la reputación de funcionar bien. Elegir un software mal escrito o intentar desarrollar una alternativa propia novo – puede dar lugar a percances como la fuga de claves o la revelación de información secreta a terceros no autorizados. Esto es lo que había detrás de una vulnerabilidad explotada recientemente en Herramienta de direcciones personalizadas de Blasfemias. Antes que nada, debe quedar claro que la billetera en cuestión utiliza una biblioteca y un proceso de generación de claves auditados y de buena reputación.

• Usa carteras que midan el doble y corta una y otra vez

Incluso si el código utiliza bibliotecas criptográficas acreditadas, aún debe integrarse correctamente. El software examinado normalmente configurará los parámetros correctos de forma predeterminada, pero puede haber lagunas en la ejecución. Por ejemplo, se requiere una fuerte fuente de entropía, o una dosis de aleatoriedad matemática, para que las claves que se generarán sean impredecibles y, por lo tanto, más seguras. Para ciertos procesos de generación de claves, como para muchos algoritmos de computación multipartita (MPC), en los que se deben generar y coordinar muchas claves separadas, o fragmentos, fragmentos de claves, la billetera debe seguir el protocolo preciso según lo especificado por el algoritmo. El algoritmo también puede requerir varias rondas de cálculo, así como claves de actualización, que la billetera debe integrar correctamente para mantener la seguridad de los fondos.

• Usa una billetera que pueda guardar secretos

La fase final del proceso de generación de claves involucra la operación real y la salida del software. Tenga en cuenta dónde se generan las claves y en qué forma.

Idealmente, las claves deben generarse en hardware aislado y la información debe cifrarse con un algoritmo confiable. Un ejemplo de uno débil que debe evitarse es el Estándar de cifrado de datos, o DES, que hoy es considerado roto. Las claves que se dejan en texto sin formato, especialmente en la memoria, en el disco o en la zona intermedia entre esos dos lugares conocidos como "intercambio", son un gran riesgo para la seguridad. En general, el material clave no debe dejar el hardware en el que se genera y no debe escapar a las redes a las que otros pueden acceder. (Es decir, a menos que el material de la clave esté cifrado, en cuyo caso la clave de cifrado también debe protegerse).

Las llaves de Slope, la billetera que fue pirateada este verano, se registraron en texto sin formato en servidores externos después de generarse. Este es el tipo de falla de seguridad que podría haber surgido en una auditoría o implementación de código abierto del código. Las billeteras que carecen de transparencia (con código de fuente cerrada, sin auditorías de seguridad de terceros disponibles para el público) deberían generar señales de alerta. 

Seguridad de billetera de almacenamiento de llaves

Después de generar las claves, deberán guardarse en algún lugar, nunca en texto sin formato, siempre encriptados. Pero simplemente poseer el dispositivo en el que se almacenan las claves no equivale necesariamente a la propiedad y el control de la clave. Se deben considerar muchos factores, como la seguridad de la cadena de suministro del dispositivo, qué tan conectado está el dispositivo y con qué otros componentes interactúa el dispositivo. Además, cada método de almacenamiento tiene su propio conjunto de compensaciones entre seguridad, accesibilidad, mantenibilidad y usabilidad.

A continuación, desglosamos las categorías más comunes en función de su nivel asociado de riesgo percibido. 

Mayor riesgo: billeteras "calientes"

El concepto en realidad no tiene mucho que ver con la temperatura. Cuando se trata de opciones de almacenamiento clave, una billetera se considera "caliente" si está conectada a Internet. Una billetera se considera "fría", por otro lado, si está fuera de línea y aislada. En igualdad de condiciones, las billeteras frías son más seguras que las billeteras calientes, pero también son más difíciles de acceder y usar. Una billetera que está conectada a cualquier red es más susceptible a los ataques, ya que permite a los atacantes tener más oportunidades de acceder para descubrir y explotar vulnerabilidades.

Las billeteras calientes pueden tomar algunas formas.

• Software conectado: bases de datos en línea, memoria de la aplicación del servidor web o del teléfono, extensiones del navegador

Estas son las opciones más arriesgadas. Aquí, el software de la billetera, con custodia o no, tiene acceso directo a las claves, todo mientras está conectado a Internet externo. Idealmente, las claves deberían cifrarse, y el otro conjunto de claves utilizado para cifrarlas debería almacenarse en un sistema de gestión de claves (KMS) dedicado con controles de acceso muy restringidos, como un llavero del sistema operativo o un sistema de gestión de claves en la nube.

Para las billeteras activas basadas en software, es fundamental aislar la gestión y la autorización de claves del resto de los componentes del software. Pueden surgir problemas en el registro, la gestión de errores y la gestión de la memoria (especialmente en el almacenamiento dinámico, donde las claves pueden no "ponerse a cero" o borrarse correctamente), todo lo cual puede filtrar por error contraseñas, claves de cifrado, claves de firma u otros datos confidenciales. material criptográfico. Cuando eso sucede, los intrusos pueden obtener acceso no autorizado a través de aplicaciones conectadas o servidores web, ataques de canal lateral o amenazas internas.

No importa cómo se etiquete un servicio, si las claves de firma no están cifradas en ningún momento en la memoria del sistema en línea, entonces el modelo debe considerarse una billetera de software caliente. (Incluso si las claves se almacenan posteriormente en reposo en un enclave seguro).

• Hardware conectado: dispositivos de propósito especial, enclaves móviles seguros, módulos de seguridad de hardware en línea (HSM)

El hardware conectado generalmente se considera menos riesgoso que el software conectado, pero aun así no es tan seguro como el almacenamiento en frío. En el hardware conectado, las claves se generan y viven solo dentro de dispositivos de hardware de propósito especial. Estos se pueden conectar a redes internas o públicas. Dichos dispositivos generalmente asumen múltiples responsabilidades relacionadas con la administración de claves, incluida la seguridad para la generación, firma y almacenamiento de claves.

El hardware conectado viene en varias variedades. Hay monederos de hardware, como los dispositivos Trezor y Ledger, que los usuarios criptográficos un poco más sofisticados suelen utilizar. (Muchas más personas deberían usar estos dispositivos, ya que son mucho más seguros que usar solo software conectado). También hay módulos de seguridad de hardware, o HSM, que se usan comúnmente en entornos comerciales más tradicionales, como los que manejan el procesamiento de datos confidenciales. , como los pagos con tarjeta de crédito.

Los dispositivos son tan seguros como la cadena de suministro que los produjo y configuró. Al considerar el hardware conectado, pregúntese: ¿Cuál es la probabilidad de que los dispositivos, o el firmware, hayan sido manipulados antes de llegar a su posesión? Para reducir este riesgo, es mejor comprar dispositivos directamente de proveedores confiables. Haga que los envíen directamente desde la fuente. Asegúrese de que los paquetes no parezcan estar comprometidos, sin rasgaduras, rasgaduras, sellos rotos, etc., lo que podría indicar una manipulación durante el transporte. También es recomendable verificar la versión del firmware y la configuración antes de su uso. Los pasos para hacerlo varían según el hardware, pero todos deben proporcionar instrucciones.

Por supuesto, siempre existe la posibilidad de que un monedero de hardware pueda ser robado o accedido por una parte no autorizada. Dadas estas amenazas, es importante asegurarse de que las billeteras de hardware también tengan capas de control de acceso seguras, garantías que garanticen que no están firmando ciegamente todas y cada una de las transacciones. Los controles pueden incluir requisitos de contraseña, avisos que solicitan permiso explícito para cada paso de una transacción y resúmenes en inglés simple que describen lo que realmente están haciendo las transacciones. Además, la mayoría de las billeteras de hardware admiten el cifrado de clave privada, también conocido como "envoltura de clave". Aún mejor, las billeteras seguras no permitirán que las claves se exporten en forma de texto sin formato, incluso si uno desea que lo sean.

Este es el nivel de seguridad que se requiere para salvaguardar verdaderamente los criptoactivos.

Menos riesgoso: monederos “fríos”

Menos calor, menor riesgo. Las billeteras frías, en igualdad de condiciones, generalmente se consideran más seguras que las calientes, aunque generalmente también son menos útiles. Las billeteras frías se denominan comúnmente billeteras "airgapped", lo que significa que no tienen conexión con ninguna red interna o pública.

La soledad es una virtud en este caso. El airgapping implica implementar rigurosas medidas de aislamiento físico y autorización. Estas medidas pueden incluir el uso de jaulas de Faraday (escudos que bloquean las señales inalámbricas), acceso biométrico (como escáneres de huellas dactilares o iris), sensores de movimiento (para disparar alarmas en caso de uso no autorizado) y SCIF, o instalaciones de información compartimentada sensible (especiales zonas de tratamiento de información clasificada).

Revisemos algunas opciones de billetera fría con más detalle.

• Software Airgrapped: aplicación de servidor fuera de línea

Debido a que un atacante puede robar o poner una máquina en línea en cualquier momento, las billeteras frías deben diseñarse con sistemas de seguridad que resistan incluso si se ponen en línea. Las claves deben dividirse en fragmentos de clave, lo que requiere que las piezas se vuelvan a unir para poder utilizarlas, a través de un método estándar, como Shamir's Secret Sharing o Multi-Party Computation. Se recomienda encarecidamente el hardware de propósito especial, como los HSM, en lugar del software conectado, ya que generalmente ofrecen más controles.

• Hardware de Airgrapped: billetera de hardware fuera de línea, módulo de seguridad de hardware fuera de línea (HSM)

Esta solución se considera la más segura de todas. Al igual que en la categoría anterior, se debe suponer que el hardware se puede robar y poner en línea. Por esa razón, es importante nuevamente que estos sistemas incluyan capas de control de acceso implementadas correctamente, como se mencionó anteriormente. Muchos proveedores de HSM requieren un quórum de tarjetas inteligentes físicas antes de poder desbloquear el acceso a las claves. Incluso si el dispositivo no tiene una pantalla, debería ofrecer alguna forma para que los usuarios verifiquen los detalles de las transacciones.

Debido a que las billeteras frías o con espacio de aire son la categoría más segura, la mayoría de los fondos administrados por grandes jugadores se almacenan de esta manera. Los principales servicios minoristas, como Coinbase, Gemini, Kraken y otros, así como servicios para usuarios institucionales como Anchorage, se encuentran entre los que lo hacen. Muchos de estos jugadores eligen tener otra línea de defensa en forma de copias de seguridad y recuperación, por si acaso, Dios no lo quiera, pierden el acceso o las máquinas se corrompen, roban o destruyen.

Copias de seguridad y recuperación

Siempre se debe hacer una copia de seguridad de las claves de firma después de cifrarlas. Es fundamental contar con redundancia tanto de claves de firma cifradas como de claves de envoltura de claves. Los métodos para hacer una copia de seguridad de una clave de firma difieren, pero uno siempre debe preferir las soluciones nativas de hardware.

Para las billeteras de hardware, las copias de seguridad suelen incluir una frase inicial de texto sin formato de 12 palabras de la que se derivan las claves privadas. Esta frase inicial debe almacenarse de forma no digital (piense en papel, metal) y de la manera más segura disponible (una bóveda física en casa, dentro de la bóveda de un banco). La frase se puede dividir en partes distribuidas geográficamente para evitar que todo el secreto se comprometa fácilmente. (La gente a veces explica este enfoque haciendo referencia a los horrocruxes ficticios que los magos oscuros usan efectivamente para "respaldar" sus almas en Harry Potter.)

Muchos HSM manejan de forma nativa algunos de los desafíos relacionados con la copia de seguridad y la recuperación. Los estándares tienen mecanismos que pueden exportar claves que, por defecto, están encriptadas con controles de acceso. Si se cumplen los controles de acceso, las claves se pueden importar a otros HSM. De manera útil, las flotas de HSM también se pueden aprovisionar con una clave de cifrado común, derivada de un quórum de tarjetas inteligentes. Separar el hardware de los materiales clave de esta manera ayuda a evitar puntos únicos de falla.

Por último, es necesario abordar los factores humanos. Los mecanismos de recuperación deben ser capaces de soportar la indisponibilidad temporal o permanente de cualquier persona involucrada en las operaciones de gestión de cuentas. Las personas deben asegurarse de proporcionar formas para que los familiares cercanos u otras partes de confianza recuperen las llaves en caso de muerte u otras emergencias. Mientras tanto, las operaciones grupales deben definir un quórum, como 2 de 3 o 3 de 5, digamos, que pueda operar razonablemente a pesar de los eventos de la vida, viajes, enfermedades o accidentes.

Seguridad de billetera de uso de clave

Una vez que las claves se generan y almacenan, se pueden usar para crear firmas digitales que autorizan transacciones. Cuantos más componentes de software y hardware haya en la combinación, mayor será el riesgo. Para reducir el riesgo, las billeteras deben cumplir con las siguientes pautas de autorización y autenticación.

• Confiar pero verificar

Las billeteras deben requerir autenticación. En otras palabras, deben verificar que los usuarios sean quienes dicen ser y que solo las partes autorizadas puedan acceder al contenido de la billetera. Las medidas de seguridad más comunes aquí son los códigos PIN o las frases de contraseña. Como siempre, estos deben ser lo suficientemente largos y complejos, utilizando muchos tipos diferentes de caracteres, para ser lo más efectivo posible. Las formas de autenticación más avanzadas pueden incluir biometría o aprobaciones basadas en cifrado de clave pública, como firmas criptográficas de muchos otros dispositivos seguros.

• No ruede su propia criptografía (¡otra vez!)

Las billeteras deben usar bibliotecas criptográficas bien establecidas. Investigue un poco para asegurarse de que estén auditados y sean seguros para evitar la fuga de material clave o la pérdida total de claves privadas. Para complicar el asunto, incluso las bibliotecas confiables pueden tener interfaces no seguras, como sucedió recientemente con estas bibliotecas Ed25519. ¡Ten cuidado! 

• reutilización nonce

Una trampa de uso de claves bien estudiada es la reutilización inadvertida de ciertos parámetros de firma criptográfica. Algunos esquemas de firma pueden requerir una nuncio apostólico es decir, "número usado una vez", un número arbitrario que solo debe usarse, bueno, una vez en un sistema. El algoritmo de firma digital de curva elíptica (ECDSA) es uno de esos esquemas de firma que lo hace. Si se reutiliza un nonce con ECDSA, puede comprometer la clave. Varios otros algoritmos no se ven afectados, por lo que, como de costumbre, asegúrese de que se estén utilizando bibliotecas criptográficas bien establecidas. (Ciertas bibliotecas criptográficas aseguran nonces únicos mediante el hash de datos de transacciones, que incluyen otros datos únicos como nonces de cuenta). Pero este vector de ataque ha sido explotado antes en hacks de alto perfil fuera de web3, como este 2010 Hackear Sony PlayStation 3.

• Una clave por propósito

Otra práctica recomendada es evitar la reutilización de una clave para más de un solo propósito. Se deben mantener claves separadas para el cifrado y la firma, por ejemplo. Esto sigue el principio de “privilegios mínimos” en caso de compromiso, lo que significa que el acceso a cualquier activo, información u operación debe estar restringido solo a las partes o el código que lo requiera absolutamente para que el sistema funcione. El principio de "privilegio mínimo" puede, cuando se implementa correctamente, limitar drásticamente el radio de explosión de un ataque exitoso. Las diferentes claves tendrán diferentes requisitos para las copias de seguridad y la administración de acceso según su propósito. En el contexto de web3, es una buena práctica separar las claves y las frases iniciales entre los activos y las billeteras, de modo que el compromiso de una cuenta no afecte a ninguna otra.

Conclusión

La naturaleza de custodia o no custodia de la propiedad de claves no es tan blanco o negro como el pensamiento convencional haría creer. La situación se complica por las muchas partes móviles involucradas en la gestión de claves, desde la generación de claves hasta el almacenamiento y el uso. Cada pieza de hardware o software a lo largo de la cadena presenta riesgos que exponen incluso las opciones de billetera supuestamente sin custodia a peligros de tipo custodia. 

Para el futuro, esperamos que se realice más trabajo de desarrollo para proteger las billeteras contra ataques y mitigar los riesgos discutidos anteriormente. Las áreas de mejora incluyen:

• Bibliotecas compartidas seguras de gestión de claves de código abierto y firma de transacciones en sistemas operativos móviles y de escritorio
• Marcos compartidos de aprobación de transacciones de código abierto

Específicamente, estaríamos particularmente emocionados de ver el desarrollo de código abierto y compartido:

• Bibliotecas de generación de claves para implementar la mejor seguridad de su clase en diferentes backends de almacenamiento (cifrado en disco, hardware seguro, etc.)
• Bibliotecas de gestión de claves y firma de transacciones para sistemas operativos móviles y de escritorio
• Marcos para flujos de aprobación de transacciones que implementan verificación de factores sólidos, como biometría, aprobaciones basadas en PKI, recuperación de autorización, etc.

La lista anterior no es exhaustiva, pero es un buen punto de partida. Todo esto es para decir que la situación es más complicada de lo que indica el eslogan “ni tus claves, ni tu criptografía”. La posesión de claves es un asunto complicado dadas las muchas partes y fases que interactúan desde la generación y el almacenamiento hasta el uso. 

Si ya está trabajando en un proyecto que aborda cualquiera de los anteriores, o si está interesado en hacerlo, comuníquese con nosotros. Esperamos más avances en estos frentes.

***

Editor: Robert Hackett, @rhhackett

***

Las opiniones expresadas aquí son las del personal individual de AH Capital Management, LLC ("a16z") citado y no son las opiniones de a16z o sus afiliados. Cierta información contenida aquí se ha obtenido de fuentes de terceros, incluso de compañías de cartera de fondos administrados por a16z. Si bien se tomó de fuentes que se consideran confiables, a16z no ha verificado de forma independiente dicha información y no hace declaraciones sobre la precisión actual o duradera de la información o su idoneidad para una situación determinada. Además, este contenido puede incluir anuncios de terceros; a16z no ha revisado dichos anuncios y no respalda ningún contenido publicitario incluido en ellos. 

Este contenido se proporciona solo con fines informativos y no debe considerarse como asesoramiento legal, comercial, de inversión o fiscal. Debe consultar a sus propios asesores sobre estos asuntos. Las referencias a cualquier valor o activo digital son solo para fines ilustrativos y no constituyen una recomendación de inversión ni una oferta para proporcionar servicios de asesoramiento de inversión. Además, este contenido no está dirigido ni destinado a ser utilizado por ningún inversionista o posible inversionista, y bajo ninguna circunstancia se puede confiar en él al tomar una decisión de invertir en cualquier fondo administrado por a16z. (Una oferta para invertir en un fondo a16z se realizará solo mediante el memorando de colocación privada, el acuerdo de suscripción y otra documentación relevante de dicho fondo y debe leerse en su totalidad). Cualquier inversión o compañía de cartera mencionada, referida o descritos no son representativos de todas las inversiones en vehículos administrados por a16z, y no puede garantizarse que las inversiones serán rentables o que otras inversiones realizadas en el futuro tendrán características o resultados similares. Una lista de inversiones realizadas por fondos administrados por Andreessen Horowitz (excluyendo inversiones para las cuales el emisor no ha otorgado permiso para que a16z divulgue públicamente, así como inversiones no anunciadas en activos digitales que cotizan en bolsa) está disponible en https://a16z.com/investments /.

Los cuadros y gráficos proporcionados en el interior tienen únicamente fines informativos y no se debe confiar en ellos al tomar cualquier decisión de inversión. El rendimiento pasado no es indicativo de resultados futuros. El contenido habla sólo a partir de la fecha indicada. Todas las proyecciones, estimaciones, pronósticos, objetivos, perspectivas y/u opiniones expresadas en estos materiales están sujetas a cambios sin previo aviso y pueden diferir o ser contrarias a las opiniones expresadas por otros. Consulte https://a16z.com/disclosures para obtener información adicional importante.