Monthly Archives: July 2015

Implications for Eddystone-URL in Chrome 44

When I wrote in my last post about Eddystone, I was not aware of Chrome already included an update to scan nearby Eddystone beacons.  Chrome version 44.0.2403.65 available in Apple AppStore (not in Play Store as of writing) now let Chrome user to open an URL broadcasted by Eddystone-URL.

This change is profound ! The following are the implications

  1. Developer no longer needs to write IOS codes to assess functionality offered by beacons . This is a liberation from the Apple iBeacon which must use native iOS APIs.
  2. A web developer can now add physical object interaction to their website. Website content can be targeted to a micro location.
  3. Security wise, the URL is unfiltered. A curious user clicking on a broadcasted URL may be directed to malware infected website.
  4. Privacy wise, by enabling Eddystone and use Chrome to launch the URL. Google knows where you are even when GPS is turn off or blocked. The Eddystone beacon location is your location. Therefore Google has a better “insights” of locations and time of your activities with a 20m accuracy.

Likely Firefox and other browser will follow and enable Eddystone. Will test out this feature with my Raspberry PI BLE project and write in next blog post.

Eddystone-URL opens doors to opportunities and threats

Google launched a beacon Eddystone project and created a new ecosystem connecting physical items with Internet. Estimote Eddystone page gives an example : “The URL could be a regular web page providing relevant information—e.g., a beacon next to a movie poster could broadcast a link to a YouTube trailer. It also could be a dynamic web application, with contextual parameters embedded in the URL—e.g., http://my-restaurant.com/check-in?restaurant_id=6523.”

How true is this statement? What are the infrastructures needed to enable this seamless integration between physical and virtual? More importantly, what are the security and privacy implications? 

The importance of Eddystone project comes from its introduction of an open source format for broadcasting a URL from physical items. In laymen’s term, it enables every physical object to have a unique URL through a BLE device sticking to it. Any smartphone following the protocol will grab the Bluetooth signal, decode it and bring a web page showing relevant info. It is much more flexible than iBeacon which only show UUID, Major and Minor.

Implication is that you DO NOT need to type the web link manually when you see a poster. The poster and your smartphone talks and show the website. NFC does this also but the distance is too short. BLE has an effective range of 20-30 meters.

Sounds simple but currently no browser is able to receive Bluetooth signal by default. The future implementation will require the user to install a mobile app specifically built with Eddystone functions. Take the example mentioned in Estimote Develop Doc, Youtube app needs to launch a new version with Eddystone enabled and show the trailer. (Given Google owns Youtube , it is a massive advertisement opportunity for Youtube.)

User Experiences Issues

On user experiences, I reckon that a new version of Youtube will add a “Scan nearby” button and when pressed, a list of URL (broadcast via EddyStone protocol) will be shown to user to select. Youtube will have hyperlocal targeting capability and be able to show relevant videos relative to where the user stands.

However,  it is not that convenient and promising. Eddystone-URL is an open standard and not encrypted, due to business competition each mobile app developer will not decode received URL if it is not from their own company. A Nike shopping-app will not show a Starbuck URL even it detects a strong signal. To enjoy the benefit and browse the information advertised by Eddystone-URL, a user needs to change app every time he move from one shop to the other. Actually the major road block is user must already know which app to launch. For movie poster, it maybe YouTube app. For car parks, it may be the car park operator app? or the shopping mall app? Or just google map? Launching the wrong app will not be able to decode the URL and display relevant information.

Changing apps frequently and prior knowledge to identify which app to launch are not impediments to wider adoptions of EddyStone. Would it be nice if Google release a new version of Chrome which will accept URL input in additional to the decade-old address bar?

When Chrome is Eddystone enabled, user will be able to see suggested URL from the surrounding environment. Each Eddystone-URL enabled physical object will broadcast their own URL and a smartphone user will be able to select which object most interest them. When this happens, there are security concerns.

Security Issues for unfiltered Eddystone-URL

The prime objective of Phishing emails and Spear-phishing is to lure users in clicking an URL and visit a website. Sometimes, the URL brings up a website which already infected with malware. Other times, the exploit is already in the URL. If there is another channel to deliver a maliciously crafted URL to users’ smartphone, I am sure attackers or cybercriminals will welcome it with open arms! Like most of the Internet standards, security features is missing in the first version. (Anyone remember what happen with the first Wifi standard was released!) The Eddystone protocol does not provide to mechanism to validate or authenticate the broadcasting URL. Eddystone only specifies the data format and application layer security is missing. If a user see a broadcasted URL in browser and there is no easy way to validate its content is secure, out of curiosity the user will likely open the URL and find out what is it. Their smartphone may be infected with malware if the website is controlled by cybercriminals. When browsers enabled with Eddystone-URL, there is a risk of bogus beacons broadcasting URL pointing to phishing websites. This will hugely impact the adoption and usefulness of Eddystone-URL.

A filtering mechanism or URL authentication is essential to the wide adoption of Eddystone-URL. Broadcasting URL from physical objects will enable lots of innovative applications by directly bring rich content to our physical world. However, when this technology gains majority acceptance, security and user protection is a must.

CCSP-isc2

CCSP , joint project from CSA and ISC2

(All comments and blog posts are personal opinions. Not related to any organisation.)

I like to share an exciting news about Certified Cloud Security Professional (CCSP℠). This week I received an email from ISC2 on awarding me CCSP designation. The blue color of CCSP (Certified Cloud Security Professional) Logo from ISC2 resembles the sky in a sunny day. Same as the sky here in Singapore.

Risks of running application and services on the cloud has been an impediment  and people (journalist in particular) tends to see the cloudy side! I involved in many discussions on cloud security in my volunteer works in CSA Hong Kong & Macau Chapter. Some of the concerns are valid , in particular the lack of experienced professionals and knowledge framework.

CCSP with the support from CSA and ISC2 is the answer to these concerns. In 2013, visionaries (like Aloysius Cheang from CSA APAC and Hord Tipton from ISC2 ) in both organisations joined together in response to market needs. In the past two years, A few other volunteers from CSA and I worked with ISC2 and their consultant Pearson VUE to develop CCSP CBK and examination questions. It was a rewarding experiences.

The process administrated is very structured and all rounded, with concept mapping, team discussions and psychometric analysis. As a security professional, I am thinking maybe system development life cycle (SDLC) should also make use of similar validation process to ensure each feature implemented is user facing and also balanced!

Developing Cloud Security certification is a challenge due to its extensive scope. The final CBK covers six domains:

  • Architectural Concepts & Design Requirements
  • Cloud Data Security
  • Cloud Platform & Infrastructure Security
  • Cloud Application Security
  • Operations
  • Legal & Compliance

Very few people acquired working experiences in all six domains. However, learning cloud technology knowledge and applying security principles in a virtualised environment are both achievable via CCSP CBK. Studying CCSP domains and passing the exam will help security professional to gain knowledge in a structure way, thus able to demonstrate their security skills are not outdated.