wi-fi asset tracking
G2 Microsystems – Enabling Wi-Fi Tags in a Supply Chain
Background G2 Microsystems’ Wi-Fi Asset Tracking System allows assets to be tagged and monitored while traveling through a supply chain. The system is available from G2 and selected development partners. The G2 Wi-Fi Asset Tracking System consists of two components: Wi-Fi Asset Tags and the Tag Engine, a telemetry server which logs all of the tag information. When combined with a company’s existing Wi-Fi infrastructure, the tracking and monitoring of assets is enabled across the supply chain. This document describes the system setup and configuration of Wi-Fi Asset Tags for a supply chain visibility solution. Wi-Fi Asset Tags are attached to assets, allowing their location and their condition to be monitored at each node in the supply chain. When the asset arrives at a supply chain node, its identification is communicated to the Tag Engine, resulting in an arrival event. This can occur without the need for integration with the supply chain node partner’s software or hardware infrastructure. In addition, the condition of the asset may have been actively monitored while in transit and this data log may also be uploaded to the owner of the tag once it has arrived at a supply chain node. Monitoring may include: • temperature • tamper • shock • humidity • customized monitoring with additional sensor hardware - e.g. gas leakage • historical location tracking when enabled with Skyhook technology (USA only) In summary, Wi-Fi Asset Tags can be attached to assets to seamlessly monitor the condition and location of those assets in the supply chain. Upon arrival at a supply chain node, they alert the owner and upload condition and location information. Low Total Cost of Ownership G2’s Wi-Fi Asset Tags leverage the existing infrastructure of 802.11-based wireless LAN (WLAN) technology already deployed in most supply chain node sites. This technology deployment has been driven by the wireless needs for barcode and RFID readers, VoIP phone technology, PDAs and portable laptops. G2’s Wi-Fi Asset Tags simply leverage this existing technology infrastructure and do not require the expensive rollout of proprietary technology at each site.
wi-fi asset tracking
Once connected to the WLAN network, G2’s Wi-Fi Asset Tags are effectively miniature computers on the internet. They do not require integration with the middleware at the node’s site and can send information directly to the owner of the tag. The Network Access Challenge G2 Wi-Fi Asset Tags leverage existing infrastructure, can actively monitor an asset’s condition and can send information to the tag’s owner upon arrival at a supply chain node without the need for complex software integration. Network access is the only hurdle that needs to be overcome to enable this technology in the supply chain. Network access means allowing the Wi-Fi Asset Tag to access the WLAN infrastructure at a supply chain node. Typically the IT department that controls this WLAN infrastructure has applied strict security guidelines, making it difficult for the tag to garner the access it requires. G2 Microsystems has been working with Cisco Systems® and other leading WLAN equipment providers to address this challenge without compromising the security of the wireless network infrastructure. While there are many ways to address this network access challenge, this paper recommends two possible approaches depending on the situation. 1. Telemetry over EAP. 2. Restricted access with wireless VLAN technology. Telemetry over EAP is the preferred mechanism as it brings the benefits of proven Public Key Infrastructure (PKI) key management and allows the tag to transmit data without accessing the enterprise data network of the supply chain node. The second alternative, restricted access with wireless VLANs, is a backup approach that is suitable for use when Telemetry over EAP is not practical. In both cases there is an implicit assumption that the owner of the tagged asset and the owner of the supply chain node are in a business relationship and that both parties are motivated to make the relatively minor changes required to roll out this technology. Setting up restricted access with wireless VLANs is described in a separate document. The following describes Telemetry over EAP in some detail.
wi-fi asset tracking
Telemetry over EAP
Figure 1
802.11 layer packets for authentication, association, EAP authentication and key derivation
EAP authentication packets including telemetry data
G2 Wi-Fi Tag (No IP Address)
Destination AP configured for 802.1x authentication
Local Site RADIUS authentication server acting as proxy
Tag Owner’s Authentication RADIUS sever
SAP Event Management G2 Tag Engine
Tag Owner
Figure 1 shows a tag arriving at a supply chain node that supports Telemetry over EAP. Here is what happens: • When the tag arrives at a supply chain access point (AP), the tag begins an 802.11i transaction with the WLAN controller or access point. • The local proxy RADIUS server at the AP recognizes the access request and forwards the request to the Enterprise’s RADIUS server for authentication. So far this is all standard 802.11i security infrastructure. • The Remote Enterprise RADIUS server recognizes that the request for access is coming from a wireless client (a tag) that the enterprise does not own, however it does recognize that the client belongs to a trusted partner. The remote enterprise RADIUS server makes a secure connection to the local proxy RADIUS server of the trusted partner and forwards the authentication request to the partner’s local proxy RADIUS server. This is called proxying. • The Local Proxy RADIUS Server opens authentication transactions with the tag. The tag is authenticated via an x509 certificate and a Transport Layer Security (TLS) tunnel is opened once authentication is completed. • At this stage the tag sends its small amount of telemetry data to the Local Proxy RADIUS Server through the TLS tunnel. • The remote enterprise RADIUS server extracts the telemetry data and forwards this information to the G2 Tag Engine, where the data is stored. From here the data can be reformatted and forwarded to enterprise-level software systems such as SAP® Event Management.
wi-fi asset tracking
• The remote enterprise RADIUS server then denies network access to the tag. This denial is passed to the local proxy RADIUS server at the WLAN controller or AP and the AP denies WLAN access to the tag. The tag is never granted access to the network infrastructure of the enterprise therefore the high security level of the enterprise WLAN is not compromised. Advantages of Telemetry over EAP Solves a significant supply chain problem • Allows location and sensor data to be sent (in any format) to the tag owner and other designated parties • Does not need middleware integration at remote sites Low security impact at remote sites • An extension of EAP-TLS (industry standard) or EAP-FAST (Cisco supported) plus other EAP methods under consideration • Supports certificates and PKI infrastructure • Revocation of security credentials on a per-tag basis • No pre-shared key distribution hassles Supports session resumption for very long-lived session-ids • Dramatically reduces power consumption in the tag while retaining certificate-based security High Security • Telemetry data is sent inside TLS tunnel • The tag never needs to be granted normal network access to transfer the telemetry data Simple one-off configuration at target sites • No on-going key management issues at remote or partner sites • All key management contained to tag owner’s site Configuring a System for Telemetry over EAP Referring to Figure 1, there are 6 components to consider when deploying a Telemetry over EAP system: 1. WLAN Controller and/or Access Point 2. Local RADIUS server 3. Enterprise RADIUS server 4. G2 Tag Engine 5. Third-party enterprise software 6. Wi-Fi Asset Tag
wi-fi asset tracking
Configuring the WLAN Controller and/or Access Point The “best practice” recommendation for configuring the WLAN is to provide a special Service Set Identifier (SSID) inside a VLAN. The VLAN is configured so that it always denies access to the data network. This provides a second level of defense, always denying access to the enterprise network for clients using this SSID, regardless of how the RADIUS servers are configured. It is recommended that SSID naming follow this specific convention: toe-node-company-location Following this naming convention has two advantages. First, the SSID that gets reported contains the location as part of the identifier. If this is not done, the Asset Tag would have to report the AP’s MAC address and the Tag Engine would have to maintain a Mac address-to-location database entry. The second advantage is that the tag can easily recognize an AP that supports Telemetry over EAP functionality (since it follows this naming convention), resulting in a significant saving in battery consumption. If the AP is already configured for 802.11ix security then it is already configured to pass authentication requests to its enterprise RADIUS Server infrastructure. If there is no RADIUS server infrastructure then the access points are probably configured for use with some kind of pre-shared key — usually WPA2-PSK. In this case there are two options: • Configure the WLAN controller or AP within a VLAN to talk directly to the receiving, not local, RADIUS server • Revert to the method of restricted access using VLAN technology mentioned above. (This is covered in a separate document, “Setting up restricted access with VLANs.”) Configuring the Proxying RADIUS Server Assuming that an enterprise RADIUS server configuration already exists then it simply needs additional configuration to enable it to provide proxy services to the Wi-Fi Asset Tag. Because proxying is a mechanism commonly used by Internet Service Providers (ISPs), it is available in most RADIUS server implementations including: • Cisco ACS • Microsoft 2003 Server • Juniper Funk Steel-Belted RADIUS® • Linux-based FreeRADIUS server The specifics for configuring each server vary, however the general concept is for the RADIUS server to recognize the realm within the tag’s identity string and forward these authentication requests to a remote RADIUS server. In this way the RADIUS server provides a proxy service, ferrying messages to and from the remote RADIUS server.
wi-fi asset tracking
Configuring the Receiving RADIUS Server: Supported EAP Methods and RADIUS infrastructure To date, there are three RADIUS servers capable of providing support for Telemetry over EAP. Each one supports a different EAP protocol and each one will be available for deployment at a different time. 1. FreeRADIUS is provided by G2 as a hosted service for the purpose of pilot trials. It supports an extension of EAP-TLS call EAP-TLS/TAG. 2. The Cisco ACS RADIUS server will deploy an extension of EAP-FAST called EAP-FAST/TAG. It will be production-ready for pilots and production use by Q3-2007. 3. Microsoft’s RADIUS Server will deploy an extension of EAP-PEAP called EAP-PEAP/TAG. This should be available in Q1-2008 depending on Microsoft’s software release schedules and the results of G2’s internal trials. Support for other RADIUS servers and EAP versions will be added depending on market demand. G2 will support pilots in 2007 with a hosted service that supports either EAP-TLS/TAG or EAP-FAST/TAG. Because it is a hosted service, no configuration of the enterprise RADIUS server is required; it is preconfigured and maintained by G2 Microsystems. Configuring the G2 Tag Engine The G2 Tag Engine is a simple server application that accepts Wi-Fi Asset Tag telemetry data formatted in G2’s Tag Telemetry Format and stores the received information in its database. This information can then be viewed via a web interface or can be configured to be reformatted and transmitted to third-party enterprise systems such as SAP Event Management. G2 will support pilots in 2007 with a hosted service that supports the G2 Tag Engine functionality. The Tag Engine’s web interface will be the primary user interface during the pilots. Because this is a hosted service, no configuration of the G2 Tag Engine is required for pilots. Configuring Third Party Software The production version of the Tag Engine will support interfaces to several enterprise software applications. After successful completion of the pilots, G2 will assess these interface requirements. Additional Security Measures There are three optional security measures that can and should be considered in any system configuration. The first option is to provide a VPN link between the local proxy RADIUS server and the remote RADIUS server. This results in additional security on this link.
wi-fi asset tracking
The second option has already been discussed. That is the use of a wireless VLAN configuration to provide a second layer of defense around the Asset Tag’s access to the enterprise network. The third option is applicable to Cisco ACS servers. Even though they are configured as proxy servers, they can be configured to always deny network access to the Asset Tag regardless of the response of the receiving RADIUS server.
1475 S. Bascom, Suite 109 Campbell, CA 95008 Phone: +1-408-626-4812 Email: info@g2microsostyems.com www.g2microsystems.com