Category: security

ASN1 Types

ASN1 is a data interoperability format that is widely used in directory, security and network management systems. Data is stored in triplets of TLV – type, length, value (in BER, DER encoding rules). TLV allows a format that is efficient, recursive and self-describing.

The type system is the interesting aspect. A “type” is a descriptor for the data, that the TLV triplet holds. The “type” is stored as a sequence of one or more bytes. This sequence can be as small  as a single byte or be as large as needed (unlimited length). In case of a single byte “type”, the bits 7,8 represent the class of the type (4 classes exist), bit 6 represents whether type is single atomic data element or nested, and bits 5-1 encode the tag of the type.  This single byte type can hold tags from 0 to 30. If the type is outside this range 0-30, the 5 to 1 bits are set to 1, and the actual tag starts in the following bytes of the now multi-byte type. In case of multi-byte “types”, the most significant bit of each byte must be 1, except for the last byte, which must be 0.

There are atomic types and component types.

Atomic types include OBJECT IDENTIFIER types and various strings (bits, ascii, octet), integers, null .

Component types include the ordered SEQUENCE and the unordered SET, both of which types can contain one or more occurrences of different types of data. SEQUENCE OF and SET OF are component types which contain zero or more occurrences of the same types of data.

There is potential for ambiguity as to whether an Object Identifier (OID) in the tagged notation is described as a multi-byte type since the OID is itself multi-byte. It is not, it is described as a single byte ASN1 type with tag = 06 as described in the tag table here and clarified by this Microsoft example of an OID encoding. So the OID value sits in the value field of the TLV triplet, not in the type.

An example of the encoding for RSA private key in PKCS#1 is here. allows lookup of Object Identifiers. Here is a tree display for RSA private key which has OID 1.2.840.113549.1.1.1 –

What are examples of multi-byte ASN1 types ?  The EMV format used in payments and smartcards use two-byte types.

The “abstract” in the name came from a contrast to “transfer syntax notation” which is the on-wire format. The “abstract syntax” maps to “transfer syntax” via encoding rules.

For comparison, consider the XDR scheme used in SunRPC. Here the types (metadata) are not included within the protocol as tags, but defined externally in a .x file which is an input to an rpcgen compiler. Protobuf and capnproto also use external medata in a .proto file. ASN1 now supports Packed Encoding Rules (PER) which remove the tag information for greater compactness and efficiency.  Finally, while ASN1 continues to be used for highly structured information, the rapid growth of JSON/REST protocols in the identity space has been interesting.

Let’s Encrypt. Less Green ? is a service conceived to reduce the friction in enabling HTTPS on a website, by automating SSL certificate creation, validation, signing, installation and renewal. The server certificate setup which used to take hours can be done in a minute. Encryption will reduce the incidence of man-in-the-middle (MITM) attacks, which can easily insert or modify the javascript in transit.

Some of this is driven by Mozilla and its large public backers with perhaps an interest in showing the green bar and lock for more websites. A self-signed cert would also provide free encryption, prevent MITM attacks and be easy to setup but would throw an untrusted connection alert to the user.

So is LetsEncrypt encryption enough to show a green bar for a website ? Because regular certification schemes require a purchase, one has to go through a credit card verification step before being issued their cert. Certs with Extended Validation have more steps to go through. There are three types of certs based on level of validation – DV, OV, EV. Doman Validation (DV) does not try to check identity of the user and is what LetsEncrypt automates using a challenge-response scheme. Clicking on websites which use LetsEncrypt DV confirms that they display a green lock/bar (using firefox).

The problem with a widely accepted CA which has a zero cost barrier for setting up HTTPS is similar to that with the free precursor to OpenDNS.  A number of less than trustworthy websites can set themselves up as mirror images of trustworthy websites and send phishing attacks by email or sms, and an end-user has no way of telling the difference. Here’s a link on how to do just such a phishing attack with LetsEncrypt. So is LetsEncrypt making the web less secure ?

It’s true that the large number of CAs with their diverse validation mechanisms makes the existing scheme not so great – especially when CAs are compromised and/or issue bad certs (e.g Superfish, Comodo, NIC). However one could inspect the CA trusted authority and if there was reason to believe it is not trustworthy – e.g. see this pic (Chris Palmer), one could avoid clicking the link.

I think the average user should receive a better visual indication on the level of trust provided by a LetsEncrypt cert that has undergone a lower level of validation by design. Use a less green color ?

End users should be more aware of the certification process and get into the habit of explicitly checking Cert chains for HTTPS by clicking on the green lock displayed next to the URL.

CERT Warns Wind Turbines Open to Compromise

Cert issued a warning that certain wind turbines are open to compromise.

“A successful attack would allow the malicious actor to lock out a legitimate administrator and take control of the device. .. the vulnerability is easy to exploit by an attacker who does not need to be authenticated to the device, or have direct physical access to it.”

A fix is issued but no OTA updates supported .. imagine climbing each turbine to upgrade the software.

Couple days earlier CERT issued an advisory about gas detectors being compromised. Incorrect gas level reports could be hazardous to equipment and human life.

DARPA asked for proposals around automatic detection and patching of security vulnerabilities.  In addition it raised an alert abut power grid vulnerability and proposed a plan to recover from a massive power grid attack. The power grid has faced hundreds of attacks, partly because it relies on 1970s era technology which cannot be upgraded as service cannot be interrupted. The addition of SmartMeters which make it more connected can increase the vulnerability level.

Amazon S2N and OpenSSL

In the last few years a number of OpenSSL vulnerabilities have come to light.  Heartbleed was a critical one which was exploited in the field. It basically allowed a client to send a malicious heartbeat to the server and get back chunks of server memory – which can contain passwords. It was estimated that two thirds of the servers in the world had the vulnerability. The fix was to upgrade OpenSSL, revoke existing server certs and request new SSL server certs.

Heartbleed previously triggered OpenBSD to fork OpenSSL to LibreSSL and Google to fork OpenSSL to BoringSSL.

Amazon S2N is a TLS/SSL implementation that is 6000 lines of code – so it is small, compact, fast and its correctness can be more easily verified. It uses only crypto functions from openssl and reimplements the SSL layer. This is a healthy direction for IOT and for certification of SSL, for example FIPS. S2N is short for Signal to Noise.

A timing attack was recently identified against it and has since been mitigated.

Note that two factor auth solutions would actually solve the problem presented by Heartbleed. There are several solutions in this area – Authy, Clef, Google Authenticator, Duo, Okta, Oracle Authenticator, ..

Docker Container Security

A block diagram of docker is below and a description of docker daemon is here. The docker client commands talk to the docker-daemon to start one of the containers in the docker registry, or to start a process described in the command line as a new docker container. Docker provides a simple interface to linux container technology which is a lightweight VM.


A few problems with this. Who has access to the docker-daemon to control the containers ? How is integrity of the containers ensured ? How is the host protected from the code running in the containers ?

Docker recently announced a few security features in Nov DockerCon

  • to lock down the container in a registry with the container image signed with a key from hardware device Yubikey; see here for a description of original issue where image checksums were not verified by docker daemon
  • to scan the official container images for vulnerabilities
  • to run containers with a userlevel namespace instead of one that allows root access to the host. This protects the host OS as explained here. The userlevel namespace feature has been available in LXC for over an year, but not in docker.

For access control to the docker daemon there is activity with a design doc here.

Twistlock is a container security and monitoring tool that attempts a comprehensive approach – access control to the containers, runtime scanning of files for malware signatures, vulnerability scanning, looking at network packets, so on. A recent meetup on Dec 1 discussed this product. It features integration with Kerberos and LDAP.

In terms of the kernel,  processes from all containers share the same kernel, the same networking layer. So what’s the level of isolation provided to container processes. This depends on vulnerabilities in the processes themselves – how many ports are open, whether injection attacks are possible etc. If two containers are running processes and a process from the one attacks a process from another – for example memory scraping, then Twistlock can detect it only if it can identify the offending process as malware using signature matching.

A Dockerfile is used to specify a container image using commands to spec the base os, rpms, utilities and scripts. USER specifies the userid under which the following RUN, CMD or ENTRYPOINT instruction run. EXPOSE specs a port to be opened for external access. A docker image is built from the dockerfile and contains the actual bits needed for the container to run. The image can be loaded directly or pushed to a docker registry from  which it can be pulled to clients. 

Kafka Security

Kafka is a system for continuous, high throughput messaging of event data, such as logs, to enable near real-time analytics. It is structured as a distributed message broker with incoming-event producers sending messages to topics and outgoing-event consumers.  Motivations behind its development include decoupling producers and consumers from each other for flexibility, reducing time to process events and increasing throughput. Couple analogies to think of it are a sender using sendmail to send an email to an email address (topic);  or a message “router” which decides the destination for a particular message – except Kafka persists the messages until the consumer is ready for them. It is an intermediary in the log processing pipeline – there is no processing of data itself on Kafka – there are no reads for instance. In contrast to JMS, one can send batch messages to Kafka and individual messages do not have to be acknowledged.

A design thesis of Kafka is that sequential (contiguous) disk access is very fast and can be even faster than random memory access. It uses zero copy, and uses a binary protocol over TCP, not HTTP.  A quote from design link – “This combination of pagecache and sendfile means that on a Kafka cluster where the consumers are mostly caught up you will see no read activity on the disks whatsoever as they will be serving data entirely from cache”.  This along with the distributed design makes it faster than competing pub-sub systems.

A proposal for adding security to it has been underway, for enterprise use, to control who can publish and subscribe to topics – . A talk on Kafka security by HortonWorks on integrating Kerberos authentication, SSL encryption with Kafka was given at a recent meetup. The slides are at –

Of interest was an incident where the SSL patch caused the cluster to become unstable and increase latencies on a production cluster. The issue was debugged using profiling. Although SSL did increase latencies, this specific issue was narrowed to a bug unrelated to SSL in the same patch which had to do with zero copy.

How does IOT affect Identity and Access Management ? 

For the purpose of the IOT, an individual device can be abstracted as a specialized service which produces and consumes data. In addition, the device has certain capabilities to act on, or transform data on a discrete or continuous basis.

Who should have access to these services and capabilities ? It could be

  • other devices in proximity to the device
  • external services
  • certain users

Who gets access is a function of the identity of the devices, the identities of the entities accessing the service and policies governing access (which can include parameters such as location, time, role or more complex rules).

To determine access, a device should be capable of

  • identifying itself , its services and capabilities
  • obtaining authorization for the services and capabilities (before exercising them), and presenting these when requested. This authorization includes a signed access policy
  • updating or invalidating the access policy as time goes on

The access policies need to be applied to the data flows based on the identities and be rich enough to capture use cases of interest.