All Posts By

jinza

AMETIC Elections

By | AMETIC | No Comments

AMETIC celebrates its Electoral General Assembly, on November 7, 2018 in the CEOE´s Sala José María Cuevas  C/Diego de León, 50 CP. 28006 Madrid.

Trust Conformity Assessment Body presents its candidacy to represent the segment of SMEs and micro-SMEs in the AMETIC board of Directors.

Trust Conformity Assessment Body is an innovative SME security specialist that audits electronic signature systems, blockchain and security and interoperability schemes and is accredited by ENAC to evaluate qualified electronic trust service providers  in the framework of the EIDAS (Regulation UE 910/2014).

The wide knowledge of technical standards and legal environment that we possess is usually useful for our clients and we think  it can also be for the board of Directors of our association.

Being an SME, we know the challenges and difficulties of companies of this size, and we think that we can help to sensitize the management bodies of the association andother stakeholders on the importance of SMEs in the productive fabric of the country and on the Policies necessary for these companies to be able to develop and grow in a profitable way.

This is our first video as candidate:

TCAB candidacy in AMETIC elections

Security audits for projects with Blockchain and SmartContracts

By | Auditoría, Blockchain, Conformity Assessment | No Comments

According to some estimates, blockchain technology companies can expect business volumes of 6 billion euros by 2020. However, they must first deal with blockchain security vulnerabilities, which, despite their relevance, continue to be underestimated when It deals with the so-called “distributed accounting” technology (or DLT).

A comment here, to clarify the “distributed ledger” (DLT) widespread term that in my opinion should be renamed as “distributed accounting”, or better, “RJT Replicated Journal Technology” since it really registers entries in the log as they are produced, not reflecting the accounting itself.

Security vulnerabilities in block chains

Some aspects of security have to do with the use of cryptography, and given that cryptography is used intensively in blockchain contexts, there is a widespread belief that blockchain systems are inherently safe.

However, in complex systems, different attack vectors appear that must be identified and remedied, so that excessive confidence in the technology can be dangerous.

In fact, the technology called DLT is subject to a series of problems that centralized databases do not have.

The security risks of Blockchain exist, and must be recognized and mitigated so that Blockchain fulfills its promise to transform the way in which data is stored and how it affects the projects that use it.

As more government, industrial and commercial sectors adopt technology, the need to address these problems sooner rather than later becomes paramount.

Blockchain Vulnerabilities

Vulnerabilities of the interface system

One of the most likely vulnerabilities with DLT originates outside of the blockchain itself.

The interface system is the equipment that a user uses to access services based on blockchain.

In this system credentials are introduced, enough reason to attract attackers who exploit vulnerabilities. Other times, manipulating the “clipboard” the memory area used for copy and paste functions can allow an attacker to change the destination account of a transaction.

Malware detection is a desirable feature in tools that anticipate minimizing attacks on the interface system.

Security of public key cryptography

Those who propose transactions to form part of the chain (for example, value transfers in the case of crypto-assets and cryptocurrencies) sign them with a private key and give information about their public key. The private key is filed with the portfolio or equivalent mechanism. The protection of the equipment is again essential. But there are certain risks (for example, based on quantum computing) that in the future could allow obtaining the private key from the public one. To minimize risk, there are techniques associated with single-use portfolios that can be adopted.

Key backups should not be kept on the system that is used daily. And even less without encrypting.

Third party platforms

As cyber-currencies and applications using related technologies (such as DLT) become popular, the third-party solutions market will experience growth. Some possible services to be offered by third parties are:

  • Blockchain integration platforms
  • Payment processors
  • Wallets
  • Fintech entities
  • Cryptocurrency payment platforms
  • Smart contracts

These platforms use different vulnerable technologies, in addition to blockchain-specific ones. They are true Providers of Digital Trust Services and should comply with the standard EN 319 401 that the EIDAS Regulation imposes on Qualified Providers.

Control of  deployment

When a project starts or evolves within it, exhaustive tests must be carried out to detect vulnerabilities in the code before it passes to the final execution environment. This is especially relevant in smartcontracts. In the smarcontracts languages ​​such as Solidity are frequently used, with “defects” similar to those of Javascript. A case of special relevance may be to include the addresses of the portfolios in quotes. If not, the addresses are truncated and the amounts remitted can end up in an irrecoverable limbo.

Size of the block chain

Depending on the type of cryptoactive and how its transaction management system has been designed for its annotation in the block chain, it may be necessary to preserve the entire chain of blocks from its origins. Some variants allow converting the transaction history into a “status photo” from which the previous history can be discarded. Be that as it may, the more transactions are made, the more the chain grows, which can create sizing problems in the equipment in which they are managed.

51% attacks

Some cryptoactive systems with different block confirmation philosophies (PoW, Proof of Work, PoS, Proof of Stake, …) could be attacked by groups that exceed the 51% participation in the consensus mechanism. Therefore, it would be advisable to anticipate the need for reversion mechanisms and the responsibility for the execution of such mechanisms.

There have been real cases of this type of attack on Pow mechanism (theoretical until recently) that is understood knowing that a large number of mining equipment accumulation centers are built in countries where electricity is cheap and supervision is scarce

Lack of maturity of blockchain technology

In all technologies, essential lessons are learned as they are adopted and generalized. Problems are discovered and reselled. Blockchain technology is still in the early stages of development and all risks and their effects are not understood.

Risks due to insufficient standardization

Many of the blockchain systems are deployed with a “Whitepaper” and source code of the project available on Github. Although it is an exercise in transparency, it is often revealed that the promoters of such projects have little interest in knowing the standards or adopting them.

It is particularly striking in the field of electronic signature, whose main market has matured over the years giving rise to various laws and technical standards that create legal presumptions for those who adopt technology and that define the standards that facilitate their interoperability.

In contrast, the use of electronic signature technology in blockchain projects seems to come from undergraduate students who have read the basics of electronic signature theory and who ignore the advance of the standards. They look like academic exercises, instead of responding to market demands that require systems to interoperate and that their developers know the laws and standards.

Fortunately UNE and ISO (among other standardization bodies) are beginning to propose standards for the blockchain world, which should not ignore the advances made in common technologies with a certain level of maturity.

It should be remembered that standardization, against what its critics affirm, does not limit innovation but opens up new possibilities for it. And leaves solved problems that were undertaken in the past minimizing the risk of reinventing the wheel each time.

Subtle vulnerabilities

There are vulnerabilities difficult to detect that are visible after incidents of a certain magnitude. It is advisable to provide for reversion mechanisms before deployment in order to manage problems that have not been previously identified.

An example is shown by the case of “The DAO”

A “DAO” (Distributed Autonomous Organization) is a Decentralized Autonomous Organization built on some types of blockchain, with code execution functionality for intelligent contracts associated with investments in the capital of markedly digital companies. You could say that a DAO is a crowdsourcing venture capital fund that is managed on the basis of embedded smartcontracts in a chain of blocks. There are many DAOs, each created to host and execute smart contracts for specific organizations.

One of those DAO, known as “The DAO”, was founded in 2016 by members of the Ethereum team. During its creation period, The DAO made history in the field of crowdfunding by raising 150 million dollars. Shortly after, The DAO made history, once again, by being the first DAO to be pirated.

During the crowdsale, many members of the Ethereum community expressed concern that the DAO code could be attacked. Subsequently, a member of the DAO team found a “recursive error” but erroneously believed that there were no DAO funds at risk. A hacker proved he was wrong.

The attack occurred when the attacker exploited two vulnerabilities in the DAO code. The hacker knew that the code was designed to allow both a split and a transfer of tokens between accounts. The hacker also realized that the code would not update account balances fast enough to prevent the transfer of the same tokens more than once.

The hacker executed a spinoff function, creating a “child DAO” account and made repeated transfer requests from his first account in quick succession. Since the code did not decrease the original account balances after each transfer, there was nothing to prevent the same tokens being repeated about 40 times each, without destroying the original tokens.

After transferring $ 55 million in Ether, the hacker terminated the attack and some additional events happened, so I invite you to investigate this issue from which great lessons are drawn.

Call us if you need us

When serious blockchain projects are proposed, their promoters invest in technology developments that help define transaction types, identity management models, block confirmation mechanisms, block production rates and transaction limits. per block. There are many aspects that make each project different.

One that should begin to be taken into account is that of the project audit. Maybe he does not detect all the problems, but he will discover the main ones. We must begin to value what is already known and avoid making mistakes that have already been committed.

Contact the Trust Conformity Assessment Body (TCAB) if you need to audit a blockchain project.

New ETSI OIDs for signature validation services policies

By | #eIdAS, eIDAS, Electronic Signatures, OID, Qualified electronic signatures Validation, Servicios de Confianza Digital, Trust Electronic Services, Trust Service Providers | No Comments

New Draft ETSI TS 119 441 proposes new OIDs for Signature Validation Service Policy:

  • itu-t(0) identified-organization(4) etsi(0) VAL SERVICE-policies(9441) policy-identifiers(1) main (1)
  • itu-t(0) identified – organization(4) etsi(0) VAL SERVICE – policies( 9441) policy – identifiers(1) qualified (2)
That is
  • OID 0.4.0.9441.1.1 as the main policy OID for Validation Services, and
  • OID 0.4.0.9441.1.2 as the policy OID for Validation Services that identifies qualified validation services as defined in articles Articles 32 and 33 of the Regulation UE 910/2014 (EIDAS)

Article 32

Requirements for the validation of qualified electronic signatures

1.   The process for the validation of a qualified electronic signature shall confirm the validity of a qualified electronic signature provided that:

(a)

the certificate that supports the signature was, at the time of signing, a qualified certificate for electronic signature complying with Annex I;

(b)

the qualified certificate was issued by a qualified trust service provider and was valid at the time of signing;

(c)

the signature validation data corresponds to the data provided to the relying party;

(d)

the unique set of data representing the signatory in the certificate is correctly provided to the relying party;

(e)

the use of any pseudonym is clearly indicated to the relying party if a pseudonym was used at the time of signing;

(f)

the electronic signature was created by a qualified electronic signature creation device;

(g)

the integrity of the signed data has not been compromised;

(h)

the requirements provided for in Article 26 were met at the time of signing.

2.   The system used for validating the qualified electronic signature shall provide to the relying party the correct result of the validation process and shall allow the relying party to detect any security relevant issues.

3.   The Commission may, by means of implementing acts, establish reference numbers of standards for the validation of qualified electronic signatures. Compliance with the requirements laid down in paragraph 1 shall be presumed where the validation of qualified electronic signatures meets those standards. Those implementing acts shall be adopted in accordance with the examination procedure referred to in Article 48(2).

Article 33

Qualified validation service for qualified electronic signatures

1.   A qualified validation service for qualified electronic signatures may only be provided by a qualified trust service provider who:

(a)

provides validation in compliance with Article 32(1); and

(b)

allows relying parties to receive the result of the validation process in an automated manner, which is reliable, efficient and bears the advanced electronic signature or advanced electronic seal of the provider of the qualified validation service.

2.   The Commission may, by means of implementing acts, establish reference numbers of standards for qualified validation service referred to in paragraph 1. Compliance with the requirements laid down in paragraph 1 shall be presumed where the validation service for a qualified electronic signature meets those standards. Those implementing acts shall be adopted in accordance with the examination procedure referred to in Article 48(2).