Specific Criticism of CVSS4
Marc Ruef
How Ideal Home Automation Works
Home automation can be discussed on different levels. We will first look at intelligent lights, aiming for the most convenient and efficient implementation possible. In doing so, we will see what limitations time-controlled mechanisms have, how to work with motion detectors and how to establish them as intelligently as possible. The center of these considerations will be the products of Philips Hue, Aqara, Apple HomeKit and Amazon Alexa.
Most people start into home automation with intelligent lights. These are either lamps or light fixtures that are networked and can be controlled via smart devices. Pioneers in this field are the solutions of the Philips Hue series, which can convince with a high quality of workmanship and reliability. Partially compatible with the system, but significantly cheaper, are the lamps of the Trådfri from Ikea.
Luminaires are installed by replacing existing components. Classic light fixtures are typically operated by wall switches that turn the current flow on or off. With smart light fixtures, the flow of electricity must be constant, as they must be able to accommodate network communication even when not lit. Those who are used to turning off lights via wall switches will need some time to get over this habit.
Turning lights on and off via a mobile app is relatively complex. Instead, existing outlets can be made smart or replaced directly with smart outlets. A cost-effective alternative is to attach NFC chips, which can be used to trigger simple automations contactlessly, for example by a smartphone.
However, the goal should be complete automation. For luminaires, this can happen in some cases on a time-controlled basis. There are typical, repetitive routines that can be mapped in this way. For example, getting up at 07:15, which will require the light in the corridor for 30 minutes. After that, it can be automatically turned off again. HomeKit offers that triggered automations are switched off again after a certain time.
However, static time specifications are only useful if the illuminated room is actually dark at the given time. For example, because the event will always take place early in the morning. Or the room has no windows. However, it is problematic when the position of the sun and daylight saving time change the requirement for light. To counteract this, it is possible to work with the position of the sun. In this case, it is necessary to find out at what position of the sun a room begins to require the artificial light. We will discuss this challenge in detail later.
The networked components are typically operated via an alternative protocol for wireless communication. Solutions such as Zigbee (IEEE 802.15.4) and Z-Wave (proprietary) have excelled here, offering short latency, high reliability and low power consumption compared to the classic WiFi (IEEE 802.11). A corresponding hub must be used so that these can be integrated into an existing network.
Even if different manufacturers use the same protocols, it does not mean that a hub can also operate different components. Philips Hue, for example, comes with its own hub based on Zigbee. New standards like Thread and Matter should simplify things in this regard.
There are components that do not use any of the aforementioned protocols, but can be controlled via classic WiFi. The previously mentioned advantages are lost, while independence from proprietary hubs is gained. Experience shows that WiFi products do not provide sustainability in this context.
Using compatible devices and ecosystems makes it possible to control them in a centralized way. A corresponding logo can be found on products that support HomeKit, Alexa, Google or Tuya, for example.
In many cases, the HomeKit functionality does not have to be switched on manually, as the manufacturer-specific iOS app does this automatically. In certain solutions, the networking has to be activated first to be able to integrate.
It is worthwhile to use the same naming conventions for rooms, components, scenes and automations in the proprietary solutions right from the start. In the ideal case these are also taken over immediately. If not, at least you don’t have to get used to different names.
In order to use the full functionality of HomeKit, a Home Hub must be used. This is the only way to use certain automations and remote access when you are not at home. Apple TV, HomePod or an iPad can be configured as a home hub. The latter is not recommended because the reliability leaves much to be desired. On the other hand, it has been announced that this functionality will no longer or very limited being available starting with iPadOS 16.
Introducing and maintaining a well thought-out naming convention for rooms, components, scenes and automations helps to ensure clarity and prevent problems.
Naming rooms is relatively simple: living_room, dining_room, kitchen, corridor, etc. Care should be taken here not to introduce collisions between rooms. For example, because there are two bedrooms. These should then also not be called bedroom 1 and bedroom 2. Instead, descriptive names, such as Parents’ Bedroom or Noah’s Bedroom, should be used.
Large rooms intended for different activities may be subdivided. For example, as Living Room and as Dining Room (even though it is the same room). Later, these can be combined into a group called Living Area.
When naming the components, room names should not be used. So a lamp in the bedroom should not also be called bedroom. Many systems, including HomeKit, do not allow such a collision. Instead, the lamp should be named according to its appearance (e.g., standing lamp), function (e.g., bookcase), or position in the room (e.g., window).
Different components with the same names can occur in a house, as long as they are located in different rooms. However, including these components with the same name in certain ecosystems can cause problems. For example, Alexa will list two different components named Stehlampe also twice with this same name. At first glance, it will not be obvious in which room they are located. Or HomeKit will refuse duplicates if they were introduced as grouped items. To counteract this, the room name can also be included in the component name. Stehlampe then becomes Stehlampe Wohnzimmer. This redundancy has an unattractive effect and, depending on the ecosystem, makes controlling specific components complex (e.g., voice control with Alexa). Ideally, however, scenes are used and specific components are never accessed.
A scene defines a predefined setting that can be created with a simple instruction. For example, certain lights are turned on and shutters are lowered. When naming scenes, the same collisions can occur as with rooms and components. So here, too, care should be taken to ensure unique naming. So dedicated scenes named Dark cannot be created in both Bedroom and Living Room. Instead, Sleeping Dark and Living Dark should be used.
And one last point should be noted regarding Automations, which in turn can also introduce collisions, but on the other hand can be responsible for unnecessary complexity if there are a lot of automations. Automations should be named according to the scheme place-time-event. For example, as Kitchen Morning On and Kitchen Night Off. The introduction of the event designation prevents collisions with scenes from being possible.
Events can be triggered by sensors. To be able to implement an alarm system, typically magnet-based contact sensors are used that can detect the state of doors and windows (open/closed). The choice of these solutions that are compatible with HomeKit are unfortunately limited. The ecosystem of Aquara, a subsidiary of Xiaomi, has emerged as a cost-effective solution.
When purchasing Aqara products, care must be taken to obtain the _EU version. The strict requirements of the EU General Data Protection Regulation have forced the manufacturer to rethink some of its concepts. Although this may promise more privacy, you have to be aware that a large part of the data is sent via the Xiaomi cloud in China.
Aqara comes with its own hub, which is also based on Zigbee, but is not compatible with Hue. The hub comes in different versions, with the “M1S” variant:https://www.aqara.com/en/smart_hub_m1s.html standing out because it comes with a warning light and speaker. There is also a USB stick-based variant as well as various indoor cameras that can be operated as a hub.
The Aqara components have to be paired via the Aqara hub. To do this, the corresponding type must be selected in the Aqara app, the hub selected, and the button on the component pressed for 5 seconds. An M1S will confirm the successful pairing acoustically with its speaker.
Just like with the Hue app, naming, assigning to rooms, creating scenes as well as automations can now be done in the Aqara app for the in-house components. These are not automatically synchronized with HomeKit. A synchronization of the naming can be triggered manually in both directions.
The basic configuration of the alarm system should be done in the Aqara app. Here, four different states and their behavior can be defined:
It can be determined which sensors are used in which profile and which state triggers which alarm.
Networked cameras can be used as an extension to an alarm system. The disadvantage of many solutions is that they are provided by third-party providers, which in turn require a login and the use of their server infrastructure. On the one hand, this raises additional privacy issues. On the other hand, it has negative influences on reliability and sustainability. For example, if a provider decides that the server infrastructure is no longer accessible for certain camera models, the affected devices can no longer be used.
Eve Cam”:https://www.evehome.com/en/eve-cam, which does not require a manufacturer login or proprietary infrastructure, has distinguished itself. Instead, it can be integrated directly into HomeKit. Content can then be streamed with any iCloud account. This can be allowed either only for local access or also for remote access via the Internet.
Cameras have the ability to detect and automatically record movements. Thanks to the HomeKit Secure Video (HKSV) function, recordings can be saved directly to iCloud. Depending on the number of cameras intended for this, an upgrade of the iCloud account must take place. Certain cameras may need to be streaming only, so recording will only remain necessary for a few.
HomeKit offers support for rudimentary object detection. This can optionally distinguish between the following objects:
If the synchronization of photos via iCloud Photo is also activated in the iCloud account used, face recognition can optionally be switched on. The known faces will be displayed in case of alerts and documented in case of recordings. This also makes it possible to disable alerts for certain people, for example because they live in the same household.
The same motion detection can also be used as a trigger for further actions. Unfortunately, this motion detection is very unreliable. This then affects both recordings and triggers. Those who need constant and reliable recordings should switch to a dedicated system with local data storage.
Depending on the situation, cameras may cover areas that should not trigger or record. For example, when public areas are in view. For this purpose, Zones can be used in HomeKit. With these, it is specifically defined which areas are to be exclusively taken into account.
It is recommended that any further automations only be done in one place. Even if the proprietary ecosystems try to shine with their own additional possibilities, the basic functions can often be implemented in HomeKit. Thus, centralized and secured automation can be aimed for. Especially when unwelcome debugging becomes necessary, this simplicity will be appreciated.
For example, Aqara’s contact sensors are displayed as such in Homekit. These can now also be used as triggers, detecting specific states (contact is open) as well as state changes (contact open/closed). For example, lights can be switched on or messages can be issued via Alexa (e.g. “The living room door has been opened”).
In order to trigger situation-specific actions, it is worthwhile to use motion detectors and vibration sensors. Conventional motion sensors rely on classic infrared, which means that detection can also occur at night. Vibration sensors can detect small vibrations or tilts. Once a change is detected, an action can be triggered. This is typically done by turning on the light. HomeKit itself does not provide for controlling the amount of motion required for this. However, the components of Philips Hue and Aqara can be customized in the proprietary apps.
Motion sensors usually come with light detection, which can detect the illuminance of a room. This is done using lux (lx):
The lux (symbol: lx) is the SI derived unit of illuminance, measuring luminous flux per unit area. It is equal to one lumen per square metre.
Not all motion sensors also pass this data through to HomeKit. Philips Hue’s motion sensors are exemplary here. The brightness data of the inexpensive Aqara sensors is unfortunately reserved for the proprietary app.
On the one hand, the current lighting can be used to set it as a prerequisite for actions. For example, the light could turn on when motion is detected. But only if the room has less than 50 lx.
Meanwhile, HomeKit can also use a change in the lux value as a trigger. This lends itself to implementing situation-based automations. For example, the light is automatically switched on at 6:30 in the morning. However, this should only switch off again when an outdoor sensor detects a value of more than 800 lx. In this way, unpleasant effects introduced by the dependence on the statistical position of the sun on cloudy days can be prevented.
The big challenge in this approach is to be able to define the thresholds in an intelligent, stable and sustainable way. In this context, immediately adjacent values should not be used for switching on and off:
<1000 lx -> Ein
>1000 lx -> Aus
This can lead to a constant switching on and off being established with minimal but regular changes. Instead, work should be done with sufficient spacing to be able to establish relaxation:
<800 lx -> Ein
>1500 lx -> Aus
This does mean that lights burn a little longer on average. But this is negligible both in everyday life and in the electricity bill.
The challenge is to find out which areas need to be illuminated at which lux values. Ideally, one light sensor can be used per room, allowing specific local values to be used. Alternatively, a well-exposed outdoor sensor can be used to provide guide values.
It is worthwhile to perform a statistical evaluation for its location. By determining average, maximum and minimum values, ideal thresholds can be determined. There are apps, such as HomeLog and Controller for HomeKit, that store historical values. Aqara also does this for its own sensors (but they do not pass the data to HomeKit).
This can also be done on Apple devices with a shortcut. For example, the movement of a motion detector is taken as the trigger. Whenever this occurs, the lux value of the light sensor is read out and transmitted to a web server. There, the data is logged in a log file.
<?php error_reporting(0); $light_val = preg_replace('~\D~', '', $_GET['light']); $light_len = strlen($light); if($light_len && $light_val < 10000){ $file = '../private/homekit_outdoor_lightlevel.txt'; $status = date('Y-m-d H:i:s')."\t".(int)$light_val."\n"; $msg = 'OK'; $fp = fopen($file, 'a'); fwrite($fp, $status); fclose($fp); }else{ $msg = 'Error'; } echo $msg.' ('.(int)$light_len.')'; ?>
Unfortunately, two or more values of a sensor cannot be reliably read out in the same shortcut. For example, it is not possible to transmit both brightness and temperature. Probably due to a TOCTOU race condition, sometimes only one value is accessible and the other is erroneously reported as 0
.
For an evaluation, a Philips Hue outdoor sensor was installed at a height of about 4m above a lawn facing south. An analysis of the typical development shows that the subjective perception of everyday life is moving away from the numbers. The following graph illustrates three consecutive days. The first was very changeable, partly cloudy during the day. The second had only a few patches of clouds. And the third was sunny throughout.
For all of them, 1 lx is displayed at night and 15-30 minutes before sunrise, it announces itself with 2 lx. A value above 1’000 lx is usually reached almost 2 hours after sunrise. A day can be very changeable and reach values between 500 and 5’000 lx at noon without any problems. The maximum measured value was 6’119 lx, the average is 1’959 lx and the median 1’603 lx.
Accordingly, it is recommended to use conservative average values, which are best compared over several days and normalized over extended time windows (e.g. 5 minutes).
By installing the Alexa skill Hue a connection between Philips Hue and Alexa becomes possible. This requires an account link with the login data of Hue.
The existing naming of devices is automatically adopted. On Alexa, the individual rooms must be set up additionally. On an Alexa with a screen, this makes access significantly easier. If the devices are then pushed into the individual rooms or group, they can also be addressed more easily or directly via voice commands:
Custom routines can now be created where a sensor can be defined as a trigger. For example, a window opening can be detected and the hint Back door was opened can be spoken automatically in case of such a window opening.
Among other things, an intelligent cat bell can be established based on this approach. A motion detector can be installed at ankle height. As soon as a movement is detected, a bell sound can be emitted. In the process, as is common with Alexa routines, the active time period can be defined. For example, false alarms at night can be prevented by only activating the routine during the day.
Timeouts can be taken one step further. Alexa can recognize when a motion detector (or another sensor) was last triggered. If this triggering occurred a certain amount of time ago, an action can be initiated. This is ideal for extinguishing the lights in rooms without a presence.
When installing the motion detectors, it is not only important to ensure that they are triggered as early as possible when a room is entered. But that they can also regularly monitor the entire room, in order to be able to recognize a presence as such throughout.
In private households, a timeout of 1-2 minutes has proven effective in most rooms. In rooms where there may be a presence but not much movement (e.g. toilets), a timeout of 5 minutes may be preferred to prevent the lights from constantly switching on and off.
It is necessary to take into account how the sensors work. On the one hand, understanding the cool-down is important. Older motion sensors from Aqara were only able to recognize a new motion as such after 2 minutes. On the other hand, it is important to understand if a new triggering resets the existing timeouts or if they are ignored.
Certain concerns are warranted when using voice assistants such as Alexa. The use of additional mechanisms can introduce risks to privacy, security and reliability of the system. These aspects must of course be taken into account here as well and, as usual, a trade-off must be made between benefits and dangers.
In our tests, it sporadically occurred that the routines of motion sensors no longer worked. These did trigger demonstrably in the Hue or Homekit app. However, Alexa was not able to work on them immediately or with a delay. To be able to restore the regular operating state, new devices should be searched for in the Alexa app. This resets the known devices or performs a new synchronization.
In other cases, a cleanup had to be triggered via the app on a Philips Hue Hub to end stuck definitions and routines. And sometimes, restarting the Home Hub (Apple TV) was required to get back to normal.
Home automation offers many other possibilities, the discussion of which would far exceed the scope of this article:
The components used should be updated regularly to be able to close known security gaps with patches. This applies to hubs as well as networked components such as lamps.
The configuration should only allow remote access via the Internet, if this possibility really wants to be used. If, for example, remote access via HomeKit is possible, this does not necessarily also have to be permitted in the Philips Hue app.
Securing the network is strongly recommended to reduce the attack surface and to contain the effects of compromises. This is especially because IoT devices have a reputation for being developed without a focus on security and are insufficiently supported by manufacturers in terms of updates.
If possible, traditional networking using physical cables should be preferred. Many weaknesses that are carried along by wireless mechanisms (e.g. radiation, interference) are not present there or only to a limited extent. The hubs from Aqara support WiFi, whereby only the M2 comes with an Ethernet port.
A WLAN should be operated in the band of 2.4 GHz. Many IoT devices are only compatible with this. This is more robust than its modern successor in the 5 GHz range. However, the extended bandwidth is not required, so better room penetration may be preferred. It must be taken into account that this frequency band can be heavily utilized by other WiFi installations, Bluetooth or even ZigBee. Analyzing the occupancy of the channels can help find the ideal configuration. Philips Hue and Aqara, for example, allow the channel used by Zigbee to be changed.
The WLAN should be protected with WPA2 and AES and a password that is as strong as possible. However, this can turn out to be a hassle in the medium term, because changing the WLAN password is not possible at all or only with a great deal of effort with certain IoT devices. Although it is recommended to change the password regularly, this is unfortunately practical in the rarest of cases.
To increase the robustness of the network, static IP addresses should be used. Static DHCP assignments can be used to realize a central orchestration of the components. The MAC addresses of the devices must be stored and assigned to the corresponding IP address. It is worthwhile grouping device types in IP address ranges (e.g. all network cameras in 192.168.0.140-150).
By using static DHCP via MAC anyway, a MAC address filter can also be used. This prevents new devices from being registered in the network without a concrete release of the MAC address. Although this can be circumvented as MAC spoofing with relatively little effort, it still represents an additional unwelcome hurdle for attackers.
The network for the IoT devices can be sealed off by VLAN and firewalling. Compromises of this network segment should not be possible without further ado due to restricted access options from the outside. And if the segment is compromised once, it cannot be broken out of without further ado (e.g., into the regular internal network or the Internet). However, it must be taken into account that, depending on the topology, access to a hub must be possible (e.g. Apple TV with HomeKit) or certain accesses to the Internet must be possible (e.g. remote access with Philips Hue).
Home automation introduces additional capabilities and more convenience. Through sensors, triggers can be defined to control intelligent devices. For example, time controls or motion detectors can be used to automatically turn networked lights on and off.
It is important to work out a basic concept in terms of technologies, topologies and naming conventions. This is the only way to implement a robust, reliable and secure solution. The security aspects should not be neglected, with classic topics such as WLAN encryption, segmentation and firewalling also playing an important role here.
Our experts will get in contact with you!
Marc Ruef
Marc Ruef
Marc Ruef
Marc Ruef
Our experts will get in contact with you!