A padlock and key connected to a chain

Key considerations for IoT sensor devices: 4 – Security

Executive Summary:

  • Security is critical for IoT
  • End application defines security policy requirements
  • Security is weak if device crypto key are not well protected in IoT devices
  • Best-in-class security policies for IoT sensors are achieved with tamper-proof hardware crypto key management

Details:

These days, there is hardly any mention in the media about IoT without security concerns being mentioned in the same sentence. The harsh critique of the status quo is well justified. Security is a must in great majority of IoT applications. However, security is a very loaded word, so let’s plainly clarify how it applies to industrial IoT sensor devices, without getting into the complexities of this involved topic.

What we mean here by security is the practice of defending information from unauthorized access, use, disclosure, disruption, modification, perusal, inspection, recording or destruction.

Security objectives and practices are defined by an end application. Security is a whole system concern, and, thus, it is only as good as its weakest link. Since sensor devices are part of a much larger IoT system, there is no meaning in saying whether the devices themselves are secure or not. For instance, if a device can securely handle its sensor data without being compromised, but a cloud service receiving this data has security holes, the overall IoT application is still insecure and easy to exploit.

On the other hand, what is important is to require that the devices can support security policies as defined for the system. Depending on application requirements, the security policies can be of various levels from lax to very stringent. For example, security policies for a radiation monitoring system around a nuclear reactor are very different than security policies for a public service weather station. The level of stringent-ness is always driven by an application’s criticality due to the trade off of exponential increase in cost and system complexity for better protection.

Security policies for IoT sensor devices typically deal with the requirements of authenticity, authorization, integrity, confidentiality, and adaptability/resistance of the underlying hardware system. In plain language, devices may be required to uniquely and securely identify themselves to the connecting cloud service (and vice versa), to provide restricted data access only to the users/services that have explicit authorization to do so, to protect the restricted data from being eavesdropped or hacked, and to enable on-going security bug fixes as they are discovered.

For IoT sensor devices to support such security requirements, the relevant security firmware has to be implemented in the device and the embedded hardware has to be able to run complex cryptographic algorithms in real time. This, in itself, has been a technological challenge as the embedded hardware has been often too resource constrained to run anything by the simplest crypto algorithms, if any at all.

Additionally, the security firmware is typically based on well-tested, open source cryptographic protocols. These protocols follow the best practice of separating the cryptographic operations, which are well publicized, from randomized secret keys which are the basis for all these cryptographic operations. As long as a hacker has no physical access to a sensor device, the system provides excellent security for communication link even if these crypto keys are not fully protected in hardware. However, once a hacker can gain physical access to the device (which should be assumed true for unsecured perimeter deployments) and can manage to extract the secret keys (for example via a debug access port or by monitoring electrical current signature on power supply), all the security goes out through the window and the system is compromised. What makes the matter worse is that majority of IoT communication radio standards use Pre-Shared Key cryptography (PSK). PSK combined with lax security implementation of using the same secret key for many devices (perhaps due to ignorance or laziness of personnel) results in large scale security breach. Once one device is compromised, all other devices with the same pre-shared secret key are compromised too. As the result, a deceptively secure system could be used to steal or manipulate restricted data or to stage further attacks on other parts of the system – a disaster scenario known too well from recent media headlines.

To help resist such security breaches, an effective practice is to protect secret keys and unique device identifiers within specialized hardware crypto coprocessors. They are designed to resist even sophisticated physical attacks such as reading electromagnetic signatures radiated by device or visually inspecting non-volatile memory state of the decapped IC chips. Once programmed during the sensor device commissioning, the secret keys are never again revealed externally, instead they are used by cryptographic algorithms internally within hardware, revealing only a securely encrypted output.

The concept is analogous to a hardware-based Trusted Platform Module (TPM) in many enterprise-grade PC’s which creates a “root of trust” for the security software to rely on to implement stringent security policies. Similar crypto technology that is used in multi-thousand dollar equipment is now feasible to be used in ultra low cost IoT sensor devices. However, few sensor devices implement any hardware-based protection for the secret crypto keys today.

IoT infographic

What are IoT Sensors?

Internet of Things (IoT) is such an overloaded term that it can mean many things to many people or nothing at all.  The purpose of this series of articles is to explain what some of these popular terms mean in the context of the latest technologies. Then, I will segue into something much more valuable to learn about – the anatomy of (IoT) “things”, how they fit into the larger Industrial IoT landscape, and what are the key considerations for connected sensors (“things”), especially as they relate to industrial applications.

iot

Summary:

  • IoT not a new concept – has already been proven in use
  • New technological capabilities enable amazing new applications
  • Very complex system, but can be addressed by ecosystem of experts
  • Most IoT applications will be small to medium installation size, growing organically

Details:

Internet of Things (IoT) is not a new concept. This technology has proven itself over the last decades in several business applications, such as security, fleet management, and cargo tracking. The basic concept of connecting to remote sensors was referred to as telemetry or M2M (Machine-to-Machine communication). However, what’s new about it is the enormously capable cloud technology combined with the reduced cost, improved reliability and miniaturization of wireless sensor devices that is only now possible by the latest technology advances in semiconductors. This new paradigm is starting to change the business landscape. What has not been feasible nor cost effective before for many businesses is now practical. New levels of increased productivity and cost reduction will grow businesses and improve profit margins.

IoT is an intersection of many disparate technologies and business models under an umbrella of a single, very complex system that fulfills specific business needs. The complexity is the result of many advanced technologies and products, which can be complex individually in their own right, being required to work flawlessly with each other as one system. This requires tremendous expertise in each aspect of the puzzle.

IoT System

Example of a ”typical” IoT system

Fortunately, such system complexity is typically mitigated by what is called IoT ecosystems – partnerships of companies each being expert in their own domain. They can offer pre-integrated solutions where each piece is verified to work well with other interfacing pieces. Such ecosystems can be themselves complex and dynamic in nature, depending on the end application requirements. For example, connecting an off-the-shelf temperature sensor via WiFi router to a cloud service which displays temperature history chart may involve very different ecosystem partners than an application for globally tracking perishable cargo that connects specialized sensors via international cellular networks and optimizes delivery routes based on historical and aggregated data.

Typically, high quality System Integrators are the key players that understand the multiple technological, ecosystems, and business tradeoffs to put together an effective system solution for their clients. The clients, on the other hand, are traditional businesses, such as farmers or municipality managers, that are not likely to have technology competency, but can tremendously benefit from the recent advancements in this technology.

There are some poster-child IoT applications, such as electric meter monitoring, that are driven by big companies on a large scale which cost-optimize the overall system solution. The individual system components, such as wireless electric meters, are single-purpose devices, produced in millions to make the per-unit cost very low, but the engineering costs (NRE – Non-Refundable Engineering) can be very high (well above $100K per device design). However, many IoT applications are not as developed, not as high unit-volume, and not as mature to benefit from single-purpose-built IoT sensor devices. In most IoT applications, flexibility, ease of use, and fast time to market actually provide better overall business utility and cost effectiveness.

gas sensors

What are IoT sensor devices?

The previous article – “What Are IoT Sensors?” – gave a high level overview of IoT system, now let’s drill down to what are IoT sensor devices.

Executive Summary:

  • IoT sensors are necessary components of any IoT application
  • Consist of sensors combined with communication capabilities
  • Many different types of sensors exist
  • Wireless communication is key to new applications
  • Multiple wireless standards exist since no one size fits all
  • Need a way to abstract application from sensing and communication methods

Details:

IoT sensor devices are the key ingredient in the overall IoT system. IoT sensor devices are sensors that can communicate their readings to internet cloud services for further aggregation and trend analysis. We will refer to IoT Sensor devices as “sensor devices”, “connected sensors”, “IoT sensors”, or, simply, “devices”, “sensor nodes”, “motes”, or “things” throughout this discussion.

Sensors can be of various types from a very simple on/off contact switch, through advanced poisonous gas leak detector, to a state-of-art, real-time, face recognition engine. Many sensors, like temperature, humidity, pressure, light, location, or motion can be quite universal and commonly used in many different applications. Others are specialized for specific industrial applications, for example Hydrogen Cyanide gas sensor or Fluoroborate water sensor. There are also sensors embedded in legacy industrial equipment, such as coolant pressure sensors in commercial HVAC accessible via standard industrial interfaces for onsite diagnostics, but not traditionally connected to the internet.

Sensor data communication to the cloud can be done in multiple ways from wireline to wireless communication of various complexity. While wireline communication has some important benefits (such as reliability, privacy, and power delivery over the same wires), wireless communication is the technology that is the key catalyst in the majority of IoT applications, that were not previously practical with wired systems. Recent technology advancements in wireless have mitigated or outright removed some of the traditional barriers to the widespread adoption. Reliability, channel security, long range, low power consumption, ease of use, and low cost are now reaching new levels, previously thought infeasible. To reach these capabilities, some assumptions about the end application requirements needed to be made, for instance about maximum data throughput, uplink/downlink asymmetry, or backward compatibility.

This is the area of intensive R&D, so in addition to some widely popular, open standard wireless radios, there exist many new, proprietary radios optimized for various applications with more to come in the near future. As with sensors, there is not one size-fits-all wireless radio solution for IoT, but many, each with different characteristics suitable for different applications.

Here are some examples of recently popular IoT wireless communication types: Wi-Fi, Bluetooth Low Energy (aka Smart), Zigbee (and other mesh 802.15.4 variants), cellular, LPWA (Low-Power, Wide-Area network variants: Ingenu, LoRaWAN, Sigfox, NB-LTE, Weightless), and Iridium satellite.

A pile of batteries

Key considerations for IoT sensor devices: 2 – Power consumption efficiency

Executive Summary:

  • Battery replacement impacts the bottom line
  • Power efficiency reduces operating expenses
  • Energy harvesting eliminates battery replacement
  • Power efficiency enables new energy sources, miniaturizes size, and slashes cost
  • Power optimizations is an expert domain

Details:

Many, if not most, of the IoT sensor device deployments are in remote or difficult to access locations without any power grid access, and, thus, are battery operated. This makes replacement of depleted batteries a major cost factor. While the batteries themselves may not be very expensive, the labor to access and replace them can be very high, negatively affecting operating expenses. Therefore, power consumption efficiency is one of key factors behind business case profitability, or, even, feasibility. Anybody intimately familiar with embedded hardware understands that there is no free lunch when it comes to optimizing for low power. There are many conflicting tradeoffs to balance, and it takes considerable effort, skill, and experience to produce an optimal solution – a subject, in itself, covered by scientific publications, academic books, and PhD dissertations.

However, in general, the more computationally powerful the embedded hardware, the more power it will consume or the harder it is to optimize. So, as the starting point, right hardware has to be chosen for a given task. For example, running Linux-based software to make a simple sensor readings with a powerful processor will almost always take significantly more energy than doing the same readings with a power-optimized microcontroller with no Operating System (OS).

The benefit of low power consumption of a device is not only less frequent trips to replace batteries, but also a possibility of getting rid of batteries altogether. It opens a possibility of powering a sensor device by harvesting the available energy from the environment. And, while true that even the whole households can be powered from collected solar or wind energy, the size, cost, maintenance needs of such equipment are huge. Needless to say, the lower the power consumption, the smaller, cheaper, and easier to use the energy harvesters can get. Also, more types of energy harvesting sources become feasible, for instance motion/vibration, thermal, or electromagnetic fields in addition to solar and wind.

Person reading a manual and thinking

Key considerations for IoT sensor devices: 3 – Ease of use

Executive Summary:

  • Easy to use or die
  • Using off-the-shelf components/boards is mighty hard
  • Ease of use needs to be matched to a user’s desire for flexibility
  • Ease of use can be provided for by a system based on best proven, popular software frameworks

Details:

Unless a sensor device is easy to configure and use, it will have a very limited traction in practice. The reason is simple – embedded engineers are too expensive to hire by many System Integrators or by most companies that just want to implement IoT applications in their business. At best, they may hire technicians and provide some on-the-job training for them. But, in many cases, the job will be done by non-technical personnel who understands their business process jobs, but not the details of technology. A good analogy is how personal computers are used at companies these days.

Frankly, today’s IoT devices, which encompass a wide range of technologies within a single system from sensors, through power management, through microcontrollers, through wireless/wired communications, to cloud data interfaces and devices life-cycle management, are intimidating even for seasoned embedded computer and communication experts. Defining and putting together such a complex system from individual, off-the-shelf components requires deep and specialized knowledge and skill. Furthermore, writing embedded firmware that logically connects all these components and makes the system perform its tasks in an optimal way is even harder and requires somewhat different skillset. Once the devices are prototyped and considered suitable for real-life deployment, the next step is to productize them. This development stage may dwarf the the other ones in terms of involved cost and the need for uniquely specialized knowledge: design-for-manufacturing, design-for-test, production sourcing and supplier management, logistics – to name just a few considerations. The more stringent the application requirements, such as harsh operating environment in an industrial settings, the more challenging the this stage is.

What’s needed is an industrial grade, configurable hardware platform that progressively balances the ease of use with customization capabilities to match the varying skillsets of different types of users.

With the ready-to-use, hardened hardware modules, pre-integrated firmware framework and the widely popular script programming environment that even schoolchildren and artists can use, the challenge of configuration and programming of a sensor devices is greatly simplified while still providing much flexibility and freedom that is needed. Additionally, a very quick and painless transition can be made from an application prototype to real-life deployment.

Important Finacial considerations

Key considerations for IoT sensor devices: 6 – Cost effectiveness

Executive Summary:

  • Cost-effectiveness is very important for sensor devices
  • In IoT, cost effectiveness is a system-level, not a component-level, optimization
  • Full-custom versus semi-custom versus off-the-shelf hardware is an complex application-specific tradeoff to be made

Details:
IoT systems dramatically benefit from localized data collection. The more granular the data localization, the better business decisions can be. Therefore, it is imperative for the IoT sensor devices to be cost effective to enable widespread deployments and to be able to reduce the overall business costs. Due to this desire for larger unit volume deployments, connected sensor devices need to be as as low cost as possible – cost competitive to other commodity devices with similar hardware features and capabilities.

Nevertheless, unlike many other simpler types of products, IoT is a complex system solution. To truly achieve cost effectiveness, the whole system cost has to be optimized – focusing on cost optimization of a single component may not result in the lowest overall system cost over the product’s intended lifespan.

For example, for some applications, field maintenance operational expenses (opex) may dwarf the capital expenditures (capex) for the cost of sensor devices, especially if those “things” are installed in very remote locations. Ultra low power solutions that reduce the time between battery replacements or that are self-powered by harvesting energy from their environment are proven methods of drastically reducing opex at minor increase to capex.

In some IoT applications, better quality and variety of sensors in a sensor device may allow to reduce the number of deployed sensor devices, thanks to their increased range and sensor fusion capabilities. Alternately, a device that can better compress or reduce the transmitted data, may have a huge impact on the reduction of wireless data usage and connectivity costs (for instance for satellite and cellular) or to enable switch to more cost effective methods of wireless communication (for example switching from cellular to LPWAN).

Another important tradeoff is how the sensor devices are designed and produced. This ranges from full-custom design through semi-custom design to using off-the-shelf components. The chosen approach should depend mainly on the nature of the application, specifically how many identical sensor devices are needed and if there are any special requirements to meet, for example a physical form factor, a unique type of sensor used, or operating conditions vastly different from those found in typical deployment environments.

Developing a fully custom-designed sensor device for a specific IoT application may not be a cost effective solution if the unit volume is low or even mid-size. The NRE (Non-Recurring Engineering) costs are typically very high for such custom high-tech products, and have long development and compliance certification lead times, especially those containing RF circuits. Any potential cost savings from optimizing the component BOM (Bill Of Materials) are dwarfed by the incurred NRE costs. Oftentimes, a more cost effective way is to use a multipurpose hardware platform which is amortized among many users and only to pay for any required minor customizations required to make such solution suitable for a given application.

Although the product selection process is a complex tradeoff between cost and benefits, here are some general rules of thumb:

  • For large deployments, more than 20,000 of identical units, or for specific form-factor implementation, full custom design may likely be the right choice
  • For fast time-to-market or small to medium unit deployments, it should be more beneficial to use pre-qualified off-the-shelf components if they are available. Appropriately configured modular hardware platform with off-the-shelf modules, slashes time-to-market without overpaying for the features not needed.
  • For unique IoT application requirements where off-the-shelf components don’t exist, consider a full-custom solution, but not before investigating a semi-custom solution based on multipurpose, modular hardware platform – where only a specialized module needs to be developed with other subcomponents being off-the-shelf. Many times, such chassis-based, semi-custom solution will be a more cost effective than full-custom solution as the bulk of hardware platform cost is amortized among many other users.

In any case, good understanding of the requirements for the overall business IoT application and the underlying technologies – not just sole focus on selecting the lowest cost components – is the primary factor that will determine financial success or failure in the IoT-powered business.

Bottom line: versatile, high quality, and capable IoT sensor devices are the most cost effective components for majority of IoT applications.

The inner workings of a mechanical duck, representing the complexity of modern sensors and networks

What is the anatomy of IoT sensor devices?

Executive Summary:

  • IoT Sensors include three fundamental functions: sensing, communication, and power supply, as well as additional functions: processing/system management and user interface
  • IoT application is determined by the types of sensors, cloud connectivity, power sources, and (optionally) user interface used in an IoT sensor device
  • It is possible to realize a variety of IoT applications with a single IoT sensor hardware platform by employing appropriate functional modularity and interface abstractions
  • An application processor and well defined interfaces help abstract functions for versatility and ease of use

Details:

There three fundamental functions that any IoT sensor must include:

  1. sensing the required physical conditions
  2. transmitting the sensed data
  3. being energized

Communication may be wired or wireless, direct or indirect – as long as sensor data somehow gets from the a sensor to public or private cloud service. Sensors may be internal to the IoT sensor device itself or external (perhaps embedded in another piece of equipment). If a sensor is external, IoT sensor must provide an appropriate interface to it. Energy sources may be internal (eg. batteries), external (eg. power mains), or hybrid (eg. external energy harvester source with internal rechargeable battery).

However, looking closer into an IoT sensor, there are other important functions it contains. Aside from the simplest forms of implementation, it needs some processing capability to manage the overall device operation. How and where the processing function is done depends on implementation choices, typically driven by cost and ease-of-use considerations. For instance, as some wireless radios need sophisticated processing, they may have more than enough horsepower to also provide application processing for a sensor reading and formatting. In such a case, the system management function may be combined with the connectivity function, but, potentially, at the expense of ease of reuse of the sensor processing paired with a different type of radio communication device.

Additionally, in some applications, an interactive user interface (UI) may be needed to configure or control the device operation. An UI may be as simple as an LED and a push button or as complex as touch-screen display or a GUI application on a paired smartphone. As many IoT sensors have to be fully autonomous devices, UI capability is added only whenever it is needed.

IoT application applicability is determined by the types of sensors, cloud connectivity, power sources, and (optionally) user interface used in an IoT sensor device.

For example, a Smart Agriculture IoT application used to optimize quality and yield of wine grapes may need soil moisture, temperature, and relative humidity sensors to monitor localized conditions around vines. IoT sensors for agriculture being out in large fields, need long range wireless communication to a gateway connected to internet. The sensor devices need to be powered from a harvested energy source, such as abundant solar power as there is no power grid in the field. There is no need for any UI. A suitable IoT sensor would then have the following hardware configuration:

  • Sensors: soil moisture, temperature, and relative humidity
  • Wireless radio: LPWA (low power wide area), such as LoRaWAN
  • Power Supply: self-powered from harvested solar energy with a rechargeable Li-Po battery to provide energy even during cloudy days
  • UI: none

Let’s look at another example. The IoT application is to monitor for water leaks at a school building, to warn of water damage from burst pipes during unoccupied hours (weekends and nights) before the damage to the building is extensive. The sensor is sensing for water moisture conditions (alternately it may monitor the flow of water in main supply pipe). Since the school building has adequate Wi-Fi coverage throughout, Wi-Fi radio connectivity is appropriate and low cost. There is power outlet in every bathroom, so the sensor device can be powered from an external power supply unit. UI is needed to configure wi-fi credentials during the deployment and to locate a deployed device via audible sound. A suitable IoT sensor would then have the following hardware configuration:

  • Sensors: moisture sensor (electric conductivity)
  • Wireless radio: Wi-Fi 802.11n
  • Power Supply: 5 Vdc from external power supply unit
  • UI: Wi-Fi Direct paired to a smartphone (for Wi-Fi credentials configuration) and piezo buzzer (for audible localization)

These two examples illustrate that while the details of the implementation are very different, the fundamental IoT device structure is the same. This means that a single sensor device hardware platform could be devised for seemingly different IoT applications with appropriate level of abstraction of interfaces for sensors, radio, power supply, and UI within the sensor device. Such abstraction can be achieved by employing modularity where different types of sensor iot, communication channels, and power supplies are implemented as interchangeable modules with well defined, common interfaces. A separate application processor in the chassis that connects the modules together provides firmware level of abstraction, that speeds up development time by reusing common firmware components and IDE despite variations in populated modules.

Thus, with enough insight into the anatomy of IoT sensor devices, a versatile, easy to reuse, and cost effective hardware platform that implements a great variety of IoT applications can be realized.

AT&T 2G/3G Sunset Timeline

2G/3G Sunset

Our friends at Multitech remind us about impending 2G/3G sunset with the US carriers.

Replacing the cellular-based sensor infrastructure takes time and good planning. Don’t be caught off-guard.

LoRa is a proven, low-cost alternative to LTE, especially for Smart Ag applications. Zenseio has had LoRa sensor solutions deployed on fields for the last year, and customers are happy to dramatically reduce their recurring connectivity costs.

If interested, drop us a line.

Roman Staszewski delivering a speech at the Collide Village Hackathon

IoT Hacking for a Greater Good and Profit

What will happen when you lock a bunch of hackers, entrepreneurs, and mentors into a room for two full weekends, give them powerful tools, dangle a valuable prize, and ask them to come up with an idea for an industrial IoT product? This was an experiment masterminded by my dear friend from college days, Tahir Hussain, who heads a tech accelerator – Collide Village in the Dallas metroplex. And, it was executed just recently.

On a fall afternoon last year, Tahir told me about his hackathon idea and asked me to provide mentorship as well as to sponsor Zenseio IoT hardware for the event. He was lining up the leading IoT companies as partners and successful local businessmen/entrepreneurs as mentors. It sounded like an interesting idea, so I jumped on it without hesitation.

The time commitment for everyone involved was significant. Participants, mentors, and organizers had to sacrifice their two full weekends. This attracted only the most driven, hardcore participants and filtered out just the curious ones. Still, over 120 participants signed up at the “Collidathon” and great majority survived to the finish line.

Lots of ideas flowed freely, and teams quickly formed around the most promising ones. The ideas were rough diamonds in disguise that needed to be shaped, polished, and validated.

Participants eagerly started working on business plans and prototypes. The IoT tools that were available for prototyping were Zenseio IoT devices, STMicroelectronics dev kits, Intel Edison dev kit, Senet LoRaWAN network, Microsoft Azure Analytics, and Ericsson Blockchain.

I was happy to see that the majority of teams picked Zenseio LoRa devices and it all went went very smoothly. In no time, everyone signed up for Senet account, configured Zenseio devices, and was streaming live sensor data to the cloud – Microsoft Azure or myDevices Cayenne. Many teams went way beyond expectations and started modifying hardware and firmware to add their own custom sensors.

What has traditionally been hard about hardware was actually the easiest step here. This afforded the aspiring entrepreneurs more time to focus on the core product concepts, business and application development. As some applications were using GPS for localization or asset tracking, they were able to immediately run outdoor pilots and to remotely collect reliable data with the Zenseio devices, without dangling wires as typical with Arduino and other prototyping dev kits.

At the end, the rough ideas were turned into actionable business plans and demonstrated with the functional full end-to-end prototypes. It was amazing to see what was accomplished in such a short time. And, the IoT applications that were championed strived to make the world a better place. Some examples using Zenseio devices:

  • Using environmental sensors to learn about daily patterns of elderly folks living alone and to provide immediate notification to caregivers in case of unexpected events or emergencies
  • Turn the trash in “smart” commercial dumpsters into monetized “gold”, using sensors and blockchain
  • Gamify recycling and proper trash disposal into “smart” bins to make the planet greener
  • Provide easy localization guidance for emergency responders to quickly find victims in case of emergency

The Collidathon turned out to be a success. While it was a close race, three teams won cash and an invitation to the Collide Village incubation program, totaling $20K.

For me, personally, I gained a few friends and valuable connections, and I was glad to see that Zenseio devices made very easy and quick for entrepreneurs to prototype and pilot their IoT ideas. There is nothing more inspiring than a complex IoT ecosystem of products and participants working harmoniously to address human challenges and striving to make the world a better place.

And, by the way, for fun, we also celebrated the Chinese New Year of Rooster on Saturday night at the annual “Different Approaches” party hosted by Mike and Quyen Courtney, featuring a live rooster 🙂

Tags:HACKATHON