Security Document weConnect R5910248 – 00
P 4 / 7
Barco nv | Beneluxpark 21 | B-8500 Kortrijk | Belgium
Registered office: President Kennedypark 35 | B-8500 Kortrijk | Belgium
IBAN BE49 3850 5234 2071 BBRUBEBB | VAT BE 0473.191.041 | RPR Gent, Section Kortrijk
www.barco.com
3 Users and BYOD
Users connect via a recent Chrome browser to the system. The connection is established over TLS 1.2 and
makes use of secure websockets for the control plane data. Browser content preview comes in directly from
the display nodes on the local area network over a http connection, a session ID key prevents other users
from getting this content through simple URL hacking. The session ID key is delivered after authentication
and access to the user interface over the TLS connection.
In general all media only gets transported over the university network for local participants. Exceptions to
this rule are the screenshot downloads for the whiteboards which come through the secure cloud
connection. For connections over the internet weConnect uses webRTC and relies on the webRTC security
implementation provided by Chrome. Barco advises users to always use the most recent Chrome version
available.
Content sharing makes use of MirrorOP, Airplay or Chromecast on the local network. For remote
learning, sharing scenarios where users are not on the local network webRTC connections are being used
for content sharing.
4 Display Nodes
4.1 Network connectivity and services
Display nodes share media streams between nodes to allow for the weConnect features like share to all,
viewing student pods on main displays and remote learning connectivity. Streams which stay on the local
network use the RTSP protocol with unencrypted unicast RTP streams. There are no specific security
measures on the RTSP server. A layer of defense to improve security is the local network design by
organizing all display nodes in a separate VLAN, which prevents users accessing the RTP streams.
Display Nodes upload a screenshot of what is on screen over the secure TLS connection to the cloud for
annotation purposes.
Display Nodes provide a low framerate preview of the content on the main classroom display as a JPEG
stream using a URL with a unique user session ID until the session terminates to minimize potential URL
hacking.
Display nodes each run a firewall to block access for all but the essential communication services. A
Fail2ban service automatically bans IP addresses when too many access attempts have been made to the
secure shell port 22 (SSH).
Authenticated direct local access to the device via a maintenance web server over HTTPS is available up to
Display Node version NRCv1.6 and will be removed from version NRCv1.7 onwards.
A secure shell service is active on the device, but requires port knocking before allowing users to attempt
connection to the device.
Refer to the Administration Manual weConnect to see the full list of ports used for proper functioning of
Display Nodes in weConnnect.
4.2 Physical security and access
The Display node NCN-100 has a Kensington lock to deter physical theft. The NCN-210 is rack mountable,
preferably physical access is prevented by securing the equipment rack.
On the NCN-210 it is possible to remove the SSD storage without the need for tools. On the NCN-100 tools
are required to open the device.
The BIOS is not password protected and can be altered when keyboard is attached to the display node. It
is best to prevent physical access to avoid that users tamper with the BIOS settings.
The Display Nodes have storage modules which hold configuration data. This data is not encrypted except
for passwords, which are hashed before storing as a standard security measure.