I will present this topic at APEX Tech. Check out the full schedule: http://bit.ly/2LtZW7Z
I will present this topic at APEX Tech. Check out the full schedule: http://bit.ly/2LtZW7Z
There are not many excellent available overviews of blockchain technologies. Thus, when NIST issues a draft “Blockchain Technology Overview,” it is interesting to have a look. It is a 57-page document open for public comments.
I like their description:
Blockchains are distributed digital ledgers of cryptographically signed transactions that are grouped into blocks. Each block is cryptographically linked to the previous one after validation and undergoing a consensus decision. As new blocks are added, older blocks become more difficult to modify. New blocks are replicated across all copies of the ledger within the network, and any conflicts are resolved automatically using established rules.
The document provides a high-level overview of blockchain. There are not many detailed technical descriptions. The document uses the bitcoin structure and vocabulary as all blockchains would use them. Thus, a generic block has necessary a nonce (for the Proof of Work) as well as a Merkle Tree. I am sure that many blockchains will not have such elements. Similarly, it uses the terminology of mining nodes for the validators. For consensus mechanisms that are not Proof of Work, it is not suitable. The sections dedicated to consensus (section 4) and Smart Contracts (section 6) are too light. The golden nugget is section 9: Blockchain Limitations and Misconceptions.
Nevertheless, it is worthwhile to read it and potentially to comment. Knowing the NIST, I am confident that the final document will be a reference document.
Password complexity is one of the top conflictual topics of security. According to NIST, many companies may over-complicate their password policies.
In 2003, Bill BURR (NIST) established a set of guidelines for passwords asking for long passwords. Since then, many policies requested these complex, lengthy passwords mixing characters, digits and special characters. Recently, he confessed that he regretted to have written these guidelines. In June 2017, NIST published a more recent version of the NIST 800-63B document. These guidelines are user-friendly.
In a nutshell, if the user defines the password, then it should be at least eight characters long. If the service provider generates the password, it should be at least six characters long and can even be numerical. The service provider must use a NIST-approved random number generator. The chosen or generated password must be checked against a blacklist of compromised values. There are no other constraints on the selection.
On the user-friendly side, NIST recommends:
Additional constraints are on the implementation of the verifier. The verifier shall not propose any hint. The verifier must implement a rate-limiting mechanism to thwart online brute-force attacks. The password shall be stored as a salted hash using an approved key derivation function such as PBDKDF2 or Balloon with enough iterations (at least 10,000 for PBKDF2).
Appendix A of the NIST document provides rationales for this simplification. For instance,
Many attacks associated with the use of passwords are not affected by password complexity and length. Keystroke logging, phishing, and social engineering attacks are equally effective on lengthy, complex passwords as simple ones.
Research has shown, however, that users respond in very predictable ways to the requirements imposed by composition rules [Policies]. For example, a user that might have chosen “password” as their password would be relatively likely to choose “Password1” if required to include an uppercase letter and a number, or “Password1!” if a symbol is also required.
A few cautionary notes; the addressed threat model is an online attack. It does not adequately cover offline attacks where the attacker gained access to the hashed password. The quality of the implementation of the salted hash mechanism is paramount for resisting offline attacks. Furthermore, it should be hoped that a theft of salted hash database should be identified and would trigger the immediate modification of all passwords, thus, mitigating the impact of the leak. NIST recommends using memorized secrets only for Assurance Level 1, i.e.,
AAL1 provides some assurance that the claimant controls an authenticator bound to the subscriber’s account.
Higher assurance levels require multi-factor authentication methods. The guidelines explore them in depth. It may be the topic of a future post.
NIST is a reference in security. We may trust their judgment. As we will not get rid soon of the password login mechanism, we may perhaps revisit our password policy to make it user-friendlier and implement the proper background safeguard mechanisms.
I wish you a happy, secure new year.
Six researchers from the Zhejiang University published an excellent paper describing DolphinAttack: a new attack against voice-based assistants such as Siri or Alexa. As usual, the objective is to force the assistant to accept a command that the owner of the assistant did not issue. The attack is more powerful if the owner does not detect its occurrence (excepted, of course, the potential consequences of the accepted command). The owner should not hear a recognizable command or even better hear nothing.
Many attacks try to fool the Speech Recognition system by finding characteristics that may fool the machine learning system that powers the recognition without using actual phonemes. The proposed approach is different. The objective is to fool the audio capturing system rather than the speech recognition.
Humans do not hear ultrasounds, i.e., frequencies greater than 20 kHz. Speech is usually in the range of a few 100 HZ up to 5 kHz. The researchers’ great idea is to exploit the characteristics of the acquisition system.
You may have guessed the trick. If the attacker modulates the command (fm) with an ultrasound carrier fc, then the resulting signal is inaudible. However, the LPF will remove the carrier frequency before sending it to the ADC. The residual command will be present in the filtered signal and may be understood by the speech recognition system. Of course, the commands are more complicated than a mono-frequency, but the system stays valid.
They modulated the amplitude of a frequency carrier with a vocal command. The carrier was in the range 20 kHz to 25 kHz. They experimented with many hardware and speech recognition. As we may guess, the system is highly hardware dependent. There is an optimal frequency carrier that is device dependent (due to various microphones). Nevertheless, with the right parameters for a given device, they seemed to have fooled most devices. Of course, the optimal equipment requires an ultrasound speaker and adapted amplifier. Usually, speakers have a response curve that cut before 20 kHz.
I love this attack because it thinks out of the box and exploits “characteristics” of the hardware. It is also a good illustration of Law N°6: Security is not stronger than its weakest link.
A good paper to read.
Zhang, Guoming, Chen Yan, Xiaoyu Ji, Taimin Zhang, Tianchen Zhang, and Wenyuan Xu. “DolphinAttack: Inaudible Voice Commands.” In ArXiv:1708.09537 [Cs], 103–17. Dallas, Texas, USA: ACM, 2017. http://arxiv.org/abs/1708.09537
Current machine learning systems are not designed to defend against malevolent adversaries. Some teams succeeded already to fool image recognition or voice recognition. Three researchers from the University of Washington fooled the Google’s video tagging system. Google offers a Cloud Video Intelligence API that returns the most relevant tags of a video sequence. It is based on deep learning.
The idea of the researchers is simple. They insert the same image every 50 frames in the video. The API returns the tags related to the added image (with an over 90% high confidence) rather than the tags related to the forged video sequence. Thus, rather than returning tiger for the video (98% of the video time), the API returns Audi.
It has never been demonstrated that subliminal images are effective on people. This team demonstrated that subliminal images can be effective on Machine Learning. This attack has many interesting uses.
This short paper is interesting to read. Testing this attack on other APIs would be interesting.
Hossein, Hosseini, Baicen Xiao, and Radha Poovendran. “Deceiving Google’s Cloud Video Intelligence API Built for Summarizing Videos.” arXiv, March 31, 2017. https://arxiv.org/abs/1703.09793
Ben Seri and Gregory Vishnepolsky from the society armis recently disclosed eight vulnerabilities present in various BlueTooth stacks. Their paper “The dangers of Bluetooth implementations: Unveiling zero day vulnerabilities and security flaws in modern Bluetooth stacks” thoroughly describes these vulnerabilities and derives some interesting lessons.
Some vulnerabilities may allow taking control of the Bluetooth device. These exploits do not need the target to be in discoverable mode. They just need to know the Bluetooth MAC address (BDADDR). Contrary to common belief, it is guessable even for non-discoverable devices. If the target generates Bluetooth traffic, then it BDAADR is visible in the access code. If it is not generating traffic, the widely accepted convention to use the same MAC address for Wifi than for Bluetooth may reveal it.
Once the attacker knows the BDADDR, he can use the exploits. One powerful vulnerability is due to some lack of implementation guidelines in the specifications for the “Just Works” authentication. For Android and Windows, if the attacker claims to be “No Input No output, No Man in the middle protection required and no bonding,” the target stealthily accepts the connection with limited security capabilities for a short period of time (due to the no bonding). Of course, any service that would require MiTM protection or bonding, and verifies the requirement, will refuse to operate over such connection. For Apple, the connection requests a validation by the user.
Once the attacker is linked to the unknowing target, it can try many attacks. My preferred ones are CVE-2017-0783 and CVE-2017-8628. They use a flaw in the specification of the Personal Area Network (PAN). This service has a low-level security requirement. This means that the previous attack grants access to the PAN without any authorization! The attacker can mount a pineapple attack over Bluetooth without the target being aware. In a Wifi Pineapple, the attacker impersonates an already known WIFI public network and can act as a man in the middle. In this case, the pineapple does not need to be a known network. Redoutable.
The PAN specification dated from 2003 and was never since revised. “Just works” and the newer authentication protocols were specified more recently. They changed the trust model and trust context. The older specifications were not analyzed to identify potential impacts.
The other vulnerabilities allow either buffer overflows or data leakage by exploring more than the attributed spaces.
The disclosure was part of a coordinated disclosure with Google, Microsoft, and Linux kernel team.
Conclusion: Verify that you installed the August and September security patches for your devices. They contain patches to these vulnerabilities.