FAQ

Yes.  Our Windows Mobile platform sports a SIP interface, but up until this point we have not had much demand for a full VoIP client.  This same SIP interface is ready for streaming H.264 video negotiation should a customer wish to explore this.

Yes, but that probably isn’t the best place to implement.  The heartbeat is best used to move pointers such that if one was making a video stream available as a resource/sensor, other subscriber endpoints could know that it was available via the heartbeat.  An endpoint that wished to consumer the stream would do so via the above referenced SIP stack.  Video will likely be implemented as a BTAC plugin and then expose the service to others via the heartbeat.

Possibly.  BTAC is not a Patient Record system, does not manipulate data, and is not a medical data management tool.  We merely “collect and push” data.  However, there is some gray area around our plugin interface which is requiring that we look into this question. Devices, such as PulseOx, heartrate monitors and other bio-telemetry sensors are examples of products that do need this FDA approval.

BTAC does have some ability to provide "network awareness" inside of buildings, tunnels, and hulls of ships. The BTAC software runs on Commercial Off The Shelf smartphones from any carrier. If the smartphone sports WIFI capability and WIFI is turned on, the BTAC software will also report proximity to wireless access points (WAP). The caveat being one would need to have some level of signal intelligence as to where a specific WAP was inside of a structure, or, teams can carry in small puck-sized WIFI beacons that broadcast a signal that is tied to a CONOP and designated placement location.

BTAC is a software solution that can ride on any mobile device that supports Windows Mobile 5/6, Windows XP/Vista/7 laptop, or Android 2.2 or above. If the hardware can provide alternative exfil methods and can assign an IP address, BTAC will work provided the device is using one of the operating systems described above.

BTAC leverages the Bonjour protocol to discover and communicate with other BTAC/Command Center modes on a WIFI local area network. Bonjour is conducive to this because it can navigate network hierarchies.

Yes. Blueforce will “listen” for wireless access points and report the four loudest as part of the extended presence heartbeat. The software will report decibel readings for security protected WAPs.

We have worked with a number of very small, low power devices.
• http://www.open-mesh.com/index.php/professional/professional-mini-router-us-plugs.html
• http://www.apc.com/resource/include/techspec_index.cfm?base_sku=WMR1000G
• http://support.netgear.com/app/products/model/a_id/2582
All of them need a 5V power source, but we have outfitted them with solar or landline chargeable mini power packs and they run for hours on end. In all cases, we have seen them pulled out of the COTS enclosures and put into ballistic enclosures.

Given BTAC is a software solution, we use whatever data communications path is provided us by the underlying hardware platform. We have not tested all variations, but we do not believe the solution will impact when used with terrestrial broadband smart devices.

No necessarily. If the SSID is not broadcast, others will not be able to "see" it (unless they have sophisticated signal intelligence collection gear). While turning broadcast off is one CONOP, there are others that can be used to mask an SSID and have it “blend” into a surrounding.

FIPS 140-2 certification is specific to the crypto provider which is essentially a set of cryptographic routines housed in a cryptographic software module. NIAP/Common Criteria certification is specific to how the software application leverages and makes calls into the crypto provider. The former is specific to ensuring the crypto algorithms are sound, while the latter is more specific to the application calls into the provider and ensuring there are no back doors and other.

Yes. BTAC uses a FIPS 140-2 certified 256-bit AES encryption algorithm to encrypt any data that comes in via Blueforce as well as system settings. This includes any and all extended presence “heartbeats”, updates to my contact list, file transfers, location data, and any sensor information.

Yes. BTAC provides two levels of encryption for information that moves between any two endpoints. First, we leverage TLS (transport layer security) for data link encryption. TLS encrypts the segments of network connections above the Transport Layer, using asymmetric cryptography for privacy and a keyed message authentication code for message reliability. Secondly, BTAC uses application-layer encryption which encrypts all traffic with a session-based 3DES asymmetric cipher. Sessions are rekeyed when they die and are reestablished.

No, the Android operating system is not FIPS 140-2 certified nor Common Criteria EAL2. Blueforce Tactical for Android uses its own crypto provider (OpenSSL FIPS Object Model), which is a FIPS 140-2 certified crypto provider.

Only NIAP/Common Criteria uses Enterprise Assurance Levels (EAL) which would be designated as 1, 2, 3, or 4. BTAC for Windows Mobile has been certified as EAL2. BTAC for Android has not achieved Common Criteria rating at this point, but has been FIPS 140-2 certified.

Yes, we use and enforce TLS as the underlying data link encryptor for WAN connections (those that connect to a Jabber/XMPP service), but also super-encrypt at the application level using session-based 3DES. For P2P connections, we use session-based 3DES.

We have obtained legal opinions from several of our partner organizations involved in health care and life safety applications who believe that our use of FIPS encryption as well as our reliance on global unique identifiers (versus actual names) yields HIPAA compliance. The platform will be subjected to formal HIPAA scrutiny in the coming months as part of a OEM partnership with a major mobile health management entity.

We are not. We are unaware that software can achieve a rating higher than EAL2.

BTAC data is not stored in the cloud. It is a point-to-point product that sends "messages" through an XMPP message switch. Messages CAN persist on the endpoints and/or on the Incident Commander's laptop which is also running BTAC Command Center.

BTAC does not store enduser data in the cloud or on XMPP servers. Given that XMPP is a switching protocol and uses servers as "switches", some packetized information may persist on the switch when a targeted endpoint is offline, but this depends on how the switch is configured. The moment they become available, content is transfered and purged from the switch. Specific to security, BTAC data is encrypted using a NSA FIPS 140-2 certified crypto provider meaning that data is super-encrypted prior to hitting any network and can only be unencrypted by the receiving endpoint(s). As such, BTAC can be used on top of potentially non-secure terrestrial networks.

Not at this time, but we are compliant with STIG requirements. This compliance includes support for DISA DISR mandated protocols for presence and messaging (XMPP), mapping (KML, GeoRSS), data integration standards (SOA, XML, SOAP), support for TCP/IP V6, and JITC interoperability requirements. Not to mention that our crypto provider is FIPS 140-2 certified.

Yes. BTAC plugins can be built to communicate with sensors that provide Bluetooth, IPV4/6, and hardwired serial connections (provided the handset has a USB-addressable port).

BTAC uses a plugin software architecture which allows the development of plugins that support existing investments in gear, machines, sensors, etc. As an example, the company developed a plugin for the MultiRAE+ for a Federal Law Enforcement agency. They also developed a plugin for the DoD for the Smiths Detection GID-3. The only requirement is that the legacy/existing sensor has some sort of an interface (i.e., Bluetooth, serial, IPV4/6, etc).