Posts tagged ‘security’

This week I spent good time BigChainDB folks in Berlin on Microsoft/BigChainDB hackathon – so we hacking, designing and coding together. Besides other outcome ( which should be not only barely working code in python) there’s some thought which came up into my mind and I want to share it there.

So we have devices – it can be any IoT like devices as rapsberry Pi or Riddle&Code cryptodevices which support AES, Diffie Hellman and secure way to keep keys inside of cryptomodule, or even smart cars like Kia or VolksWagen who collects car telemetry, or even musical instruments or not even device in common meaning like luxury clothes or paintings . And we would like to to get data from device or prove device authenticity and we’re going to do it in secure way. For example, we would like to get information from smart car about its telemetry/mileage and this information should be shared to new potential car owner or insurance company as important insights about smart car status.

  • Here we go to first important topic in that area – its ‘how to identify device in some kind of secure way?’. Basically from that point of view there’s two types of devices (or not devices – do you remember paintings and musical instruments mentioned before)  – first are provide some secure features like ‘I can keep private/public key’ and  second one are about ‘i don’t have any keys at all’. In first case we’re very good – there’s device which have it’s own unique keypair and this keypair can be efficiently used anywhere to identify device. In second case ( 99.95% or even more devices ) we have only properties which should be treated as publicly exposed information, for example:
    – serial number ( VIN ), mostly never changed and mostly unique, but not always – for example for VIN there’s a cases where VIN can be changed ( for example you change engine on your car, then you have new engine with new VIN, but car itself is the same )
    – consumer properties like color, size, weight and so on. Some of that properties are immutable ( like weight or size ) in case if device is in proper state, some like color can be changed easily (after washing for example ) without any affect to main functionality of our device.
    – manufacturer properties: year, factory id, name of device, person who made an assembly and so on. These properties are immutable because device got them as part of its existence/historical data. Yes, serial number is also some kind of manufacturer properties and the reason why I differentiate it from other manufacturer properties because serial number is going to treated like unique identifier, at least it has much more changes to be treated in that way than any other properties.

For these non-secure devices we do have two options kindly provided by blockchain technology – option one it’s to use One Authority center to


Guys from Amazon posts in Amazon Web Services Blog interesting document – AWS Security White Paper.
Main points –

  • there’s no backup for data ( EBS, S3, anything), but all data redundantly stored in multiple physical locations
  • for EC2 they have four security levels – host OS ( access : only AWS administrators ),  guest OS ( access : only customers, AWS admins can’t log onto guest OS ),  Firewall ( indirectly configured by customers, AWS admins also have access ) , Amazon EC2 API ( access : only customers ).
  • all guest OS running by hypervisor XEN – so instances have no direct access to hardware resources, and can’t read-write any data which owned another instances – including network packets, disk devices and memory.
  • network traffic ( for different instances ) can not be sniffed, external DDoS secured by firewal, port scanning inside network prohibited by Acceptable Use Policy ( customer will be blocked for this, I suppose ), instances can’t use IP spoofing ( because of hypervisor Xen :-). Anyway, Amazon reccomend to use SSL for network connections.
  • Security in S3 and SimpleDB based in ACL ( access control list ) – only data owner may edit access permission.
  • All data in S3 and SimpleDB stored ‘as is’ without any encryption. If you want to be more secure – you should store encrypted data – “Encrypting before sending to SimpleDB guarantees that no party, including AWS, has access to sensitive customer data”.  Once you delete data from S3 or SimpleDB all external links to them will be unaccessible – “area is then made available only for write operations and the data is overwritten by newly stored data”.  S3 and SimpleDB nodes use SSL for network connection, so there’s no chances for Man-In-The-Middle attack.