0% found this document useful (0 votes)
11 views

Datafox guide to parameterization and integration of microcontroller devices V1.19_2022.09.29_EN

This document serves as a comprehensive guide for the parameterization and integration of microcontroller devices, specifically focusing on the MasterIV and EVO series. It covers system structure, hardware and firmware setup, communication techniques, and the use of Datafox Studio for configuration without programming knowledge. Additionally, it includes details on display design, security measures, and various communication protocols, providing essential information for effective device integration.
Copyright
© © All Rights Reserved
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
11 views

Datafox guide to parameterization and integration of microcontroller devices V1.19_2022.09.29_EN

This document serves as a comprehensive guide for the parameterization and integration of microcontroller devices, specifically focusing on the MasterIV and EVO series. It covers system structure, hardware and firmware setup, communication techniques, and the use of Datafox Studio for configuration without programming knowledge. Additionally, it includes details on display design, security measures, and various communication protocols, providing essential information for effective device integration.
Copyright
© © All Rights Reserved
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 49

Guide to

Parameterization and integration


of microcontroller devices

Flexible data collection with method


Content
1. Introduction .......................................................................................................1
2. System Structure ..............................................................................................1
2.1. Structure of the hardware / device and firmware .................................................................... 2
2.2. Usable Characters ...................................................................................................................... 3
2.3. Language / Table ......................................................................................................................... 4
2.4. Displaydesigner .......................................................................................................................... 5
2.4.1. Color Setting for the Displays of the EVO 4.3 / 2.8 and 3.5 ......................................................................... 6
2.4.2. Default Setting ............................................................................................................................................. 6
2.4.3. Display function buttons on the EVO 4.3 / 2.8 und 3.5 display ..................................................................... 7
2.4.4. Upload images for function buttons of EVO 4.3 / 2.8 / 3.5 ........................................................................... 7
2.4.5. Design examples in the designer ................................................................................................................. 8

3. Creation of a setup (program) .........................................................................9


4. Device key and security .................................................................................10
4.1. Device passwords ..................................................................................................................... 10
4.1.1. Communication password .......................................................................................................................... 10
4.1.2. Bios Menu Password ................................................................................................................................. 10
4.2. Wireless security ...................................................................................................................... 11
4.2.1. Texas Instruments TI-CC3135 (Generation 2) ........................................................................................... 11
4.2.2. Redpine (Generation 1).............................................................................................................................. 12

5. Description of the different communication techniques .............................13


5.1. Overview of the communications technologies .................................................................... 13
5.2. Function overview of communication techniques ................................................................ 14
6. Communication via DLL .................................................................................15
6.1. Program library [Dynamic Link Library (DLL)] - General information ................................. 15
6.1.1. What is a program library? ......................................................................................................................... 15
6.1.2. Advantages of a program library in DLL or so-form. .................................................................................. 15
6.1.3. The communication library is available for the following systems: ............................................................. 15
6.1.4. Program library (DLL) - Integration Passive mode (polling) ....................................................................... 16
6.2. Program library (DLL) - Integration active mode (active connection) ................................. 17
6.3. Encrypting the data when using the DFCom.dll .................................................................... 18
6.3.1. Create and save a communication key for the device ................................................................................ 19
6.3.2. Save the communication key in the StudioIV ............................................................................................. 20
6.3.3. Transfer the communication key for DFComDLL ....................................................................................... 20
6.3.4. Clear the communikation key ..................................................................................................................... 21

7. http Level 0 ......................................................................................................22


7.1. Preconditions ............................................................................................................................ 22
7.2. Sending of data records via HTTP .......................................................................................... 23
7.3. HTTP response and optional parameters ............................................................................... 23
7.4. Advantages and disadvantages with HTTP ........................................................................... 23
7.5. Encryption of the data fields when sending via HTTP .......................................................... 24
8. http Level 0 with service connection ............................................................29
9. http Level 1 ......................................................................................................30
9.1. Requirements ............................................................................................................................ 30
9.2. Changes between Level 0 and Level 1 concerning Request and Response ...................... 30
9.2.1. The following changes have been made to level 0 in the request: ............................................................. 30
9.2.2. The following changes have been made to level 0 in the response: .......................................................... 30
9.2.3. Request...................................................................................................................................................... 31
9.2.4. Method: GET .............................................................................................................................................. 31
9.2.5. Response ................................................................................................................................................... 32
9.2.5.1. Optional parameter specifications for the response ................................................................................... 32
9.2.6. Encryption .................................................................................................................................................. 34
9.2.6.1. Illustrate the GET request .......................................................................................................................... 34
9.2.6.2. Encryption detection................................................................................................................................... 34
9.3. https Communication ............................................................................................................... 35
9.3.1. Requirements ............................................................................................................................................. 35

Guide to parameterization and integration page II date: 30.09.2022 V 1.19


9.3.2. Elements of the https infrastructure............................................................................................................ 35
9.3.3. Use of encryption / certificates ................................................................................................................... 35

10. Talk ..................................................................................................................36


10.1. Advantages and disadvantages with Datafox Talk ............................................................... 36
10.2. When do I use Talk? ................................................................................................................. 37
10.3. Overview of the Function Modules Talk ................................................................................. 37
10.4. Establishment of Talk ............................................................................................................... 38
11. Anhang ............................................................................................................40
11.1. Information for HTTPS .............................................................................................................. 40

Guide to parameterization and integration page III date: 30.09.2022 V 1.19


Changes within this document

Date Chapter Description


07.08.2013 Alle Neuauflage der Dokumentation
08.09.2013 Alle Ausdruckkorrektur
4.3 Hinweis Unterschiede Active-Mode -> passive Mode
14.05.2014
4.4 Onlinefunktion ZK über HTTP
11.05.2015 4.3.4 und 4.4.5 Verschlüsselung ergänzt
09.08.2016 4.2 Übersicht / online offline Funktionen der ZK ergänzt
2.2 Language
07.11.2016 2.3 Characters / Zeichensätze
4.3.4.1-4 Verschlüsselungsverfahren im einzelnen
22.12.2016 4.2 Display Designer
28.12.2017 5.6 http Level 1
28.12.2017 5.7 https
23.01.2018 4.2 wireless security
17.12.2019 5.6 More options for the http Level 1
Appendix Information for HTTPS
28.07.2020
Structure of the Chapter Main structure of the document changed
30.09.2022 All update the links

Guide to parameterization and integration page IV date: 30.09.2022 V 1.19


1. Introduction
This document is a guide to training in the topics:
a) Configuration and
b.) integration of communication
The guideline applies to all microcontroller devices MasterIV series and EVO series, as well as in-
tegrated embedded modules in the industrial PC .
(Note: The built-in Industrial PC embedded modules can also be operated in HID mode.)
This document will help you to estimate the integration effort.
There you will be given links and notes, where you will find information on each topic.

The Parameterization of the devices is done via Datafox studio. This program allows you to cre-
ate the desired acquisition and testing functions quickly, easily and without any programming
knowledge or, as we say, to parameterize. The free of charge/licence free program can be found on
our website or on the product DVD.

When integrating communication, we give you an overview of the possible communication chan-
nels with Datafox terminals. The individual channels are shown and described with their advantages
and disadvantages. On the DVD, and our website you will find sample programs for the integrati-
on of the DLL in the current programming languages for your use.

2. System Structure
This overview shows the basic structure of the complete data acquisition system and its areas:

Save the
Setup file

The following components are explained in the following chapters:

Structure of the hardware / device and firmware (Link)


Creating a setup (Link)
Communication techniques with Datafox devices (Link)

Guide parameterization and integration page 1 date: 30.09.2022 V 1.19


2.1. Structure of the hardware / device and firmware
This graphic shows the structure of data acquisition devices in context.
Underlying hardware is fitted out as desired.
Then there is the firmware, which is the operating system.
The program, which we call setup file is executed by the firmware.

The device (Hardware)

Operating system (firmware)


The setup file (program) that defines the data
collection and Logic, created with Datafox studio
and performed by the firmware.
- Record structure
- Structure of the master data
- Order of acquisition
- Detection technology such as RFID / barcode
etc.

System variables
-mobile /digital signals

Lists / strain data Global


Be called by the setup and Variables
used for selection by indica-
tion, as well as used for
plausibility checks.

This connection is important because you do not have access to the individual areas of the system
with every communication technology.

Guide parameterization and integration page 2 date: 30.09.2022 V 1.19


2.2. Usable Characters
For your information, we have put together an explanation of the characters in the standard scope of
delivery.
This information can also be found in the manuals.
The Datafox devices support a part of the character encoding Latin-1 (ISO-8859-1) for the character
output on the display and the data.

ISO 8859-1, more accurate ISO/IEC 8859-1, also known as Latin-1, is a standard for information
technology on eight-bit character encoding, updated by the ISO last 1998, and the first part of the
standards family ISO/IEC 8859.

Character Table - Latin-1:


Code …0 …1 …2 …3 …4 …5 …6 …7 …8 …9 …A …B …C …D …E …F
0…
not usable
1…
2… SP ! " # $ % & ' ( ) * + , - . /
3… 0 1 2 3 4 5 6 7 8 9 : ; < = > ?
4… @ A B C D E F G H I J K L M N O
5… P Q R S T U V W X Y Z [ \ ] ^ _
6… ` a b c d e f g h i j k l m n o
7… p q r s t u v w x y z { | } ~
8…
not usable
9…
A… NBSP ¡ ¢ £ ¤ ¥ ¦ § ¨ © ª « ¬ SHY ® ¯
B… ° ± ² ³ ´ µ ¶ · ¸ ¹ º » ¼ ½ ¾ ¿
C… À Á Â Ã Ä Å Æ Ç È É Ê Ë Ì Í Î Ï
D… Ð Ñ Ò Ó Ô Õ Ö × Ø Ù Ú Û Ü Ý Þ ß
E… à á â ã ä å æ ç è é ê ë ì í î ï
F… ð ñ ò ó ô õ ö ÷ ø ù ú û ü ý þ ÿ

SP = space, NBSP = hard coded space, SHY = conditional separator

Control characters according to ISO standard can not be used


characters can not be used
Usable characters of Firmware-Version 04.01.xx.xx to Firmware-Version 04.03.02.xx
Character extension Firmware-Version 04.03.03.xx (only Hardware V4)
character extension Firmware-Version 04.03.04
when using character table Latin-1 (only Hardware V4)

Guide parameterization and integration page 3 date: 30.09.2022 V 1.19


2.3. Language / Table
In order to ensure language compatibility, it is possible to edit the texts and messages displayed by
the firmware.
Open the editing dialog via the menu
"Configuration – Language file for device (*.dfl) – Edit file for language table".

Open a device file archive (firm- Open or create a new language file for
ware)*.dfz. The default texts of the the firmware with the extension *.dfl. If
firmware with a description and the you have created a new file, the right
corresponding message are dis- column of the list is empty.
played.

Work within the lists with single mouse Now you can enter or edit the text.
clicks only. NO double-clicks! Select a When you finish the entry, the de-
line from the list with a single click. scription form the column Default
(Description/…) is taken over and
With another single click on the column you can edit it as well.
User (Description/…) or User (Mes- You can find prepared .dfl-files on the
sage/…) the cursor is displayed in this Datafox DVD.
field.

 Note:
Cyrillic and Chinese characters can not be displayed.

You find different language file.dfl on our product DVD:


Englisch, Niederländisch, Französisch
Default setting is German. German is always included in the firmware file.

Datafox DVD\MasterIV_EVO_TimeboyIV\Datafox Geräte\Datafox Software MasterIV-04.03.07\Datafox Studio-


IV_und_Firmware\Sprachdateien der Firmware
https://www.datafox.de/d67/unternehmen/downloads/software/master4-v4/Datafox_Softwarepaket_MasterIV-V04.03.19.zip
(Laden Sie immer das aktuelle Release)
Beispiel: Datafox Software-MasterIV V04.03.19.zip

Guide parameterization and integration page 4 date: 30.09.2022 V 1.19


2.4. Displaydesigner

scope of application:

For the devices AE-MasterIV V4, PZE-MasterIV V4 and PZE-MasterIV Basic V4 the Designer
Is only usable with the optional color display.

With the Display-Designer, Datafox offers the possibility for partners and users to customize the
display according to your requirements. But due to the necessary operating sequences, this cannot
be a completely free design, but things like headlines, menu structures and footers have to be guar-
anteed. The aim of the display designer is to enable the feasible settings with minimal effort.

We are looking forward to many users and recommend:


Create an individual Display-Design for your Company:

Example picture for EVO 4.3

Example picture for EVO 2.8 / 3.5

Example picture for PZE-/ AE- Master V4 with color display

To create an individual discplay design for your device, you need at least the
DatafoxStudioIV 04.03.09.05.

The display designer can be


opened via the Configuration
menu or directly from the
setup edit mask.

Guide parameterization and integration page 5 date: 30.09.2022 V 1.19


2.4.1. Color Setting for the Displays of the EVO 4.3 / 2.8 and 3.5

Example Picture:

2.4.2. Default Setting

The device is delivered in the


default „PZE“-design.

This design is also set as de-


fault when you first create a
new theme in Display Designer. Function Key’s
are not displayed in the
default setting.

Guide parameterization and integration page 6 date: 30.09.2022 V 1.19


2.4.3. Display function buttons on the EVO 4.3 / 2.8 und 3.5 display

By showing the function


buttons from the setup,
the number of buttons
displayed in the display
can be adjusted.

Example:

2.4.4. Upload images for function buttons of EVO 4.3 / 2.8 / 3.5

Under this menu item "Key


settings" you can import the
image file for each function
key.

Sample picture for the key fig-


ures:

Guide parameterization and integration page 7 date: 30.09.2022 V 1.19


2.4.5. Design examples in the designer

With the installation of the DatafoxStudioIV you get several design examples for the devices.
Click on the "Design Examples" button to open them.

Datafox gradually extends the examples.


If you have any suggestions or wishes, please let us know.

Guide parameterization and integration page 8 date: 30.09.2022 V 1.19


3. Creation of a setup (program)
The creation of the setup is done with the free of charge "DatafoxStudioIV" tool.
The structure of the tables for master data and bookings as well as the operating procedures, are
freely definable. There are no programming skills required.

1. bookings

2. master data

3. operating +
signal Processing

4. access control

1. Insert the data structure of the tables individually for bookings


Record table: Records (Data description)
record code ID_Person Name date and time reason
K 656556 M. Müller 21.02.2013 12:31:15 0
K 656556 F. Muster 21.02.2013 12:32:45 0
Access Tabelle: Records access (Data description)
ID date and time Master ID Reader ID State
0566236654 21.02.2013 12:31:15 1 010 20
- 21.02.2013 12:32:45 1 010 42
1566959651 21.02.2013 14:12:05 1 020 20
- 21.02.2013 16:55:14 1 020 42
0000489722 42
21.02.2013 16:55:15
102451
2. Define the structure of the tables for master data.
There can be: 20 record tables and 20 list tables be defined, each with 25 fields

Lists are for example Master or order data that already exist
and in a defined shape (list description) are transferred to the
device. For example, HR master, cost centers, production
orders, etc .. These data support the data acquisition by al-
Table: Personal Data (description) lowing a choice to carry out from a list or to compare data
UID Name with a list (plausibility check).
00799611485215 M. Mustermann
05597861113494 M. Musterfrau
3. Specify the operation and signal 4. Create the Access Control
processing.

- Detection order
- menus - Status
- show text - online / offline
- Show list
- submenus
- RFID-methods
- Type of inputs

5. Transfer the setup to the terminal.

6. Collect data

Guide parameterization and integration page 9 date: 30.09.2022 V 1.19


4. Device key and security
There are different techniques for the Datafox devices to protect the device from unqualified access.

4.1. Device passwords

Device passwords are used to prevent devices from being unintentionally / accidentally or intention-
ally read or manipulated in the settings for communication or data.

These settings are only intended to ensure the operational safety of the devices and should be part
of the standard.
These settings do not have the encryption passwords.
Please see the chapter on encryption via http and DLL.

4.1.1. Communication password

Our software "DatafoxStudioIV" is freely available on the homepage.


The devices are configured by our partners.
To prevent misuse or manipulation by users, a communication password can be stored in the de-
vice. Only those who know this can change the configuration of the device.
The Password is transferred to the device with the configuration (setup file).

4.1.2. Bios Menu Password


All display devices have a bios menu.
Settings can be made as followed:
IP - address
The type of Communication (GPRS, USB, TCP/IP) etc.
Display brightness, volume etc.

To prevent access to the bios menu, a password can be entered here.


This password is then transferred to the device with the configuration (setup).

Guide parameterization and integration page 10 date: 30.09.2022 V 1.19


4.2. Wireless security
4.2.1. Texas Instruments TI-CC3135 (Generation 2)

The module is currently not available for the Universal

This overview shows you which WLAN methods are supported.

The TI-CC3135 module automatically detects the encryption of the AP. Therefore, only the Security
parameter needs to be set. The other parameters (Encryption and Authentication) are detected au-
tomatically.

Routers that operate WPA3/WPA2 in mixed mode can already be used now.

If the networks in the 5Ghz and 2.4Ghz bands have the same name, the network with the better re-
ception quality is selected. This is usually the network in the 2.4Ghz band.

WLAN - Overview of the en-


cryptions
„Infrastructure“

Secutity: Secutity: Secutity: Secutity:


WEP(1) WPA2 WPA3 NON

Encryption and Authentication


Are automatically recognised.
Only the KEY hast o be entered.

Attention:

! We cannot test every Acsess point on the market.


Therefore, it is not possible for us to guarantee a connection to every AP..

Guide parameterization and integration page 11 date: 30.09.2022 V 1.19


4.2.2. Redpine (Generation 1)

This overview shows you which WLAN methods are supported.


Not supported is WPA (Predecessor of WPA2).
Not supported is multiple-input multiple-output (MIMO)
5 GHz connections are not supported and no mixed operation 2.4 GHz / 5 GHz.
Authentication via WPA2 Enterprise according to IEEE 802.1x is not supported.

WLAN / Wifi – overview about


the encriptions and
„Infrastructure“

Security: Security: Security:


WEP(1) WPA2/802.11i None (0)
ohne

Encryption Encryption NO Key

AES / CCMP
WEP64 „AES 128“

WEP128 AES / CCMP +


WEP

Authentication Authentication
Open/None (0) Shared/PSK
Shared/PSK (1)

Attention:

! We cannot test every available Access-Point on the market.


Therefore, it is not possible for us to guarantee a connection to any AP.

Attention:

! multiple-input multiple-output (MIMO) is not supported. If you change the AP from b/g/n
to b/g, only SISO is automatically used.
https://en.wikipedia.org/wiki/Single-input_single-output_system

When setting the encryption AES or WEP, only one type is used at a time.
The setting AES+WEP means for some access points that AES encryption is performed first and
then additionally encrypted with WEP.
In this case, only set AES.

Guide parameterization and integration page 12 date: 30.09.2022 V 1.19


5. Description of the different communication techniques
5.1. Overview of the communications technologies

This overview is valid for all microcontroller devices of MasterIV series and EVO series, as well as
for the embedded modules integrated into the Industrial PC. (Note: The built-in Embedded modules
inside the Industrial PCs can also be operated in HID mode.)

DLL integration „Datafox-Talk“


DLL integration „Active-mode“ Data exchange via
„Passive-mode“ Permanent Active file storage or data-
= Polling connection to the base with a service
(free of charge) terminal (License Required)
(free of charge)

„http“ „http „http“


Level 0 Level 0 Level 1
Automatic sending with Service mode“ Automatic sending
of data to a Sending the data to a of data to a
Web Server Web server and es- Web Server
(free of charge) tablishment of a ser- and transfer list to
vice connection (free the device
of charge) (free of charge)

In order to enable the respective communication, the main communication must be set in the BIOS
of the device. How to enter the BIOS menu, please see the respective manuals in the chapter "Dis-
play structure and Bios".

Guide parameterization and integration page 13 date: 30.09.2022 V 1.19


5.2. Function overview of communication techniques

DLL http
DLL
integra- http http Level 0 Datafox
active-
access tion Level 1 Level 0 with Talk
mode Service-mode
to: description Polling
Generated data
Data sets from the data
acquisition
-staff lists
Transfer -Article Master
master data -orders
-Firmware
System -Language
-Colour/Display

System -Setup

GV
8 x free use
global
variables
System- GPRS
COM
variables I/O

Message to Direct display of


The device text on the display

Online
Mode
Online All access authori-
zations are decid-
Mode ac- ed directly from
cess the server

Access con- In case the


server is ofline:
trol alternat-
automatic
ing online change to Of-
offline fline-Mode
Access The device uses
control its own access
oflline control lists
Access The device check
control with self in the list and
send the result to
assisted onl the server. the
server then checks
Depend- 300s or
<1s HTTP <1s HTTP < 1s HTTP
Timeliness of How fast is the ing on Message more de-
via Lan, via Lan, via Lan
data ca. in generated data how often "data sets pending on
1-2s via 1-2s via 1-2s via
seconds available the data is exist" <1s the setting;
GPRS GPRS GPRS
retrieved 300s rec.
Download Downlaod: Downlaod: Download
Hinweise Windows Windows
Zusatzinfo Linux Linux Hinweise/Info

Only possible after the request for a service connection „Active-Mode“

Guide parameterization and integration page 14 date: 30.09.2022 V 1.19


6. Communication via DLL
6.1. Program library [Dynamic Link Library (DLL)] - General information
6.1.1. What is a program library?
"A program library referred in programming as a set of subroutines that provides solutions to the-
matically related problems. Libraries, unlike programs, are not stand-alone units, but auxiliary mod-
ules that are requested or called by programs."
Wikipedia about program library

In order to address the functions (subroutines) of the program library, it must be integrated into your
software solution. Depending on the development environment a certain procedure is required. In
principle, all have one thing in common: the required functions have to be announced to your soft-
ware solution (they must be declared).

6.1.2. Advantages of a program library in DLL or so-form.

Here specifically for the Datafox DLL.


 The integration of a DLL is easier and faster than the direct integration of a protocol.
 Can be used independently of the programming language..
 Single Programming Interface (API) to the different Datafox devices.
 The DLL shows defined error messages if operations can not be performed correctly.
 The DLL automatically writes log files for debugging.
 Updateable without rebuilding your software solution. Downwards compatible.

6.1.3. The communication library is available for the following systems:


As DLL for Windows 32bit, DFComDLL.dll; 64bit, DFCom_x64.dll
As Shared Library or Static Library for Linux 32/64bit libDFCom.so (Makefile)

Guide parameterization and integration page 15 date: 30.09.2022 V 1.19


6.1.4. Program library (DLL) - Integration Passive mode (polling)
In the passive mode the communication link is established starting from the program library to the
devices. For this you need a single function to establish connections and another for disconnection.

Functional principle when transferring the bookings:


The application queries the device via the DLL regularly to collect the data.

The following connection types are supported by the passive mode:


RS232 (via converter also RS485)
USB (via virtual COM-Port)
Modem (analog / GSM)
TCP / IP (LAN / WAN / WLAN)

An exemplary query of a device serial number in an device connected via TCP / IP using the C pro-
gramming language:

int err, serial;


DFCComOpenIV( 5, 0, 3, “192.168.0.3”, 8000, 3000 );
DFCGetSeriennummer( 5, 254, &err, &serial );
DFCComClose( 5 );

advantages:
 All connection types and device types are supported.
 All functions of the program library are fully available.

disadvantages:
 If you want to receive the generated data sets immediately after creation, a constant communi-
cation with the device is necessary (polling). In TCP / IP networks, this, depending on the num-
ber of units, may lead to an undesirable loss of bandwidth.
 Not recommended for mobile communications as it may cause high costs.

Guide parameterization and integration page 16 date: 30.09.2022 V 1.19


6.2. Program library (DLL) - Integration active mode (active connection)

In Activ mode, the communication link from the devices to the program library is made. Prior to this,
the devices must be informed at the time of installation where they are to be connected. In the pro-
gram library, you need a single function to start the active mode and another to end the active
mode.

The "DFCStartActiveConnection" function in this case replaces the function "DFComOpenIV" in


passive mode.
After activation of active mode in the program library this waits for incoming connections and is then
making them available for further processing in your application.

Functional principle when transferring the bookings:

The devices sign in to the DLL. This writes a list of registered devices. If a device has a booking,
this sends a trigger to the DLL. The application responds to the trigger and fetches the booking. The
necessary connection data is available in the registration list. The collection of the booking is made
with the same functions as with polling. As a result, polling and active connection upon collection of
the data differ only slightly.

The following connection types are supported by the active mode:


 TCP / IP (LAN, WAN, WLAN, GPRS)

advantages:
 The device log on independently and also report existing records.
 The application does not require a device list, since the devices sign in automatically into the
DLL and the DLL provides a list of active devices.
 All functions of the program library are fully available.

disadvantages:
 Here, since the multi-master principle is necessary, only connections by connection type TCP /
IP are supported.
More information and documentation can be found here:
https://www.datafox.de/d67/unternehmen/downloads/software/master4-
v4/Datafox_Softwarepaket_MasterIV-V04.03.19.zip

Guide parameterization and integration page 17 date: 30.09.2022 V 1.19


6.3. Encrypting the data when using the DFCom.dll
When using the Datafox communication DLL all data coming from the device or sent to the device
may be transferred with an AES 128-bit encryption.

Thus, there are only 3 types of communication:


1. Unencrypted communication
2. Encrypt with Datafox-Key
3. Encrypt with user-Key

When integrating the Datafox DFCom.dll from the application side, only a user communication key
is handed over to the .dll. The effort of integration of encryption is thus very low.

Overview of the encryption, schematic illustration.

DatafoxStudioIV

Application

Setting a commu-
nication key Setting a user communica-
in Datafox device tions Key
by transmitting a in Datafox device and
configuration file handing over the key to the
"name.INI". with user DLL
the DatafoxStudi- or activating the Datafox-
oIV. Key on the Kommu-
nikations.dll by the applica-
tion software.

Datafox communica-
tion.dll
Encrypted data AES 128 Bit key encryption with
- User-Key or
- Datafox-Key

A detailed description of how the handover of the key takes place, you will find:
o for DatafoxStudioIV in the manual in the chapter "encrypt communication with MasterIV devices"
o and for the DLL in the DLL documentation

Guide parameterization and integration page 18 date: 30.09.2022 V 1.19


6.3.1. Create and save a communication key for the device
In the menu „Configuration“ -> “System variables active mode “open the configuration file to edit.
For example: „active.ini“.

Click on the line “Key” to


open a new window and to
create a key.

Select the type of communication.

If you want the communication to be encrypted with your own stored password, enter a password
and click on the button "Create value from password".

A communication key is now created. Finish the entry with "OK".


After a key has been created and the active. ini file has been transferred, communication with the
device is only allowed if the password is entered.

Guide parameterization and integration page 19 date: 30.09.2022 V 1.19


6.3.2. Save the communication key in the StudioIV
If a device is using a communication key, then the DatafoxStudioIV needs the same key. Otherwise
no communication with the device would be possible,
In the menu „Communication -> Settings“ you may edit the key for the Communication.

The password is used for all


types of communication.

Enter your password here.

The plaintext input is only


possible at the first input.
If you reopen the window you
won’t see the plaintext.

6.3.3. Transfer the communication key for DFComDLL

The key for the communication transferred to the DLL is called “DFCSetCommunicatioPassword”.
The key has to be in plaintext (123456) and not the created key of the DatafoxStudioIV.

More information can be found in the documentation of the DFComDLL.

Guide parameterization and integration page 20 date: 30.09.2022 V 1.19


6.3.4. Clear the communikation key

If created a communication key and


transferred to the device then clear
this key as follows:

Click on “KEY” to edit.

Switch to unencrypted communication.

Click on: “Value empty“.


Then click on: “Create value from Password“. The created Value from the empty Password is nec-
essary to clear the old key in the device.

Save the file and transfer


to the device.

After this you can clear the created key from the .ini file.

Guide parameterization and integration page 21 date: 30.09.2022 V 1.19


7. http Level 0
7.1. Preconditions

Requirements for transmission of the data via HTTP:


Hardware:
Device with TCP / IP or cellular function
Software:
Server must accept an HTTP request and give an active response

Functional principle when transferring the bookings:

The devices send the data automatically and directly after their emergence to the Web server.
There, the bookings are accepted by an executable script and forwarded to the main application or
in a database.

Datafox-device Network Web-Server (executable script


e.g. php, asp, java)

Network TCP/IP or WLAN


HTTP 1.1 with free Internet access or within a HTTP 1.1
closed network. cellular connection via
GPRS

HTTP over TCP/IP


On any device that has a TCP / IP interface, you can enable the HTTP of the device in the BIOS
menu under “Communication”. For this purpose the entry "http" to "YES" is amended.
Required for sending the data with HTTP over LAN, is the correct settings of the parameters in the
.ini file and the communications must be set to TCP / IP.

HTTP over GPRS mobile network


For the use of data transfer via GPRS the device requires a SIM card, preferably with a M2M data
plan. The setting of the connection parameters is carried out via the Datafox studio and is stored in
the GPRS-ini. Please draw attention to the roaming settings, otherwise it may lead to high costs.

Guide parameterization and integration page 22 date: 30.09.2022 V 1.19


7.2. Sending of data records via HTTP

The Datafox device is able to send booking data promptly via GPRS or TCP / IP to a web server.
Example of a send string:

Plaintext request
getdatagv.php?table=BB&bTYP=Manu&bLOG=Log&bDAT=2011-05-24_08%3A30%3A12&bPER=Per&checksum=2120

Plaintext reply
status=ok&checksum=2120(Prüfsumme) (allways enter at the end: \r\n (carriage return line feed))

7.3. HTTP response and optional parameters

In the response String you can react to the request.


Expected is always one answer „status=ok&checksum=2120“.
With other possible parameters, the device may perform the following actions:
Set time
output tones
start Input string (Quasi press a virtual button)
Assign / pass values to global variables
Show messages on the display

7.4. Advantages and disadvantages with HTTP


advantages:
Fast transfer of the data
Direct online capability (eg instant display of a response on the display)
Online access control (all permissions are executed by your software)
Easy integration as php or other active scripts can be adapted very quickly and are very
common.
When using the online mode, you can dispense with the use of master data in the device.
When booking, the server can sent direct messages, such as "Good day John Doe, you have
successfully logged in", to the display.

disadvantages:
Master Data can not be transmitted to the terminal via HTTP. It has to be switched to the HTTP
service connection. See next chapter
There is no access to system variables possible.

More information can be found in the manual DatafoxStudioIV in the chapter "Configuration" ->
"System variables HTTP / GPRS"
Latest manuals are available on the homepage:
https://www.datafox.de/unternehmen/downloads/informationsmaterial#c6046

On our website you will find a test environment with detailed instructions.
You can send directly in Live mode data to the server and see them.
This is also very good for product demonstrations.
Test environment:
https://www.datafox.de/support/testumgebungen

Instructions and test setups:


https://www.datafox.de/support/testumgebungen

Guide parameterization and integration page 23 date: 30.09.2022 V 1.19


7.5. Encryption of the data fields when sending via HTTP

If data records are sent via HTTP, the field contents can be transmitted in encrypted form. The data
fields of the data set are then encrypted using a RC4 encryption. The so encrypted characters are
transferred as field contents in hexadecimal.

Overview of encryption with HTTP; schematic representation:

DatafoxStudioIV

application

Handover of a
communication
key to the Data- Your script pro-
fox device by vides the data to
transmitting a your application.
configuration file
"name.INI".

Script (php, etc.)


for the receipt of the da-
ta.
- the file "dfanalys-
er.php" already con-
Encrypted data fields tains the logic for de-
crypting the data

A detailed description of how the handover of the key takes place, can be found:
o in the manual of DatafoxStudioIV Chapter „5.4.5. “Encryption of the data fields when sending via HTTP“
o and the file "dfanalyser.php" can be found on the Datafox DVD or in the download - Software for Windows

Note:
If you use encryption for several customers, you have to pass a customer ID into the plain
text.

 This allows you to use different keys per customer.

Guide parameterization and integration page 24 date: 30.09.2022 V 1.19


Activating Encryption via DatafoxStudioIV
Open the configuration file (e.g. GPRS.ini) for editing via the menu entry Configuration "GPRS /
HTTP - Configuration".

By clicking on the line “KEY”, the


window for creating the key
opens.

Enter your password here.

By clicking the button "Create value from pass-


word", a key for transfer is generated.

Click "OK" to take the key over.


Subsequently, you can save the settings and
transfer them to the Datafox device.

Guide parameterization and integration page 25 date: 30.09.2022 V 1.19


Disable encryption
To deactivate the key which has been transferred to the device, it is necessary to create an empty
password field with the button "Clear value" and to transfer this empty key to the device.

Click on „Value empty“

Click on "Create value from


Password“.

and then on „OK“

Save this file with the new key.

Guide parameterization and integration page 26 date: 30.09.2022 V 1.19


Klick on “Write to device“

Now the key in the device is


deleted.

The records are then sent unencrypted.


After this you can clear the key from the file.

Deactivating Encryption
In order to deactivate the key transferred to the device, you must create an empty password field by
clicking the button "Empty value" and transfer the empty key to the device.
The data records are then sent unencrypted.

Illustration of the GET Request


in plaintext (unencrypted) and encrypted:

Plaintext request
getdatagv.php?table=BB&bTYP=Manu&bLOG=Log&bDAT=2011-05-24_08:30:12&bPER=Per&checksum=2120

Plaintext response
status=ok&checksum=2120 status=ok&checksum=2120

Encrypted request
getdatagv.php?dfcb=1000&table=e977&bTYP=14dce883&bLOG=4d7876&…&checksum=c01de865&dfce=019c1bd2

Encrypted response
dfcb=1000&status=2b97&checksum=1726950d&…&setup_2=a449fd9c&setup_blue=a9375c8d0672&dfce=b99239f3

Detection of an Encryption
In order to detect whether the data fields are sent encrypted, the beginning of the encryption is
marked with 'dfcb' (Datafox Crypt Begin) and the end is marked with 'dfce' (Datafox Crypt End).
'dfcb' is the first field of the GET request and 'dfce' the last field.

The value of the field 'dfcb' is transferred in plaintext and is the 'public key'. It is a random number
between 1000 and 9999. Combined with the user password, the value must be used for encryption
and decryption.

Encryption of data thus is achieved by "private key + public key" as password key.

Guide parameterization and integration page 27 date: 30.09.2022 V 1.19


In the response, the field 'dfcb' must be returned exactly. This ensures that decryption has been
successful and the response matches the request.

The value of the field 'dfce' is the same as 'dfcb' but it is transferred encrypted. During encryption it
can be ensured that the key used is correct. The value of 'dfce' must equal the value of 'dfcb' after
encryption.

If problems occur during encryption, the response 'dfc=error' must be sent. Additionally, information
must be entered in the fields 'dfcb' and 'dfce'.

The following errors must be considered by the evaluating script:

'dfcb' is not a number or is outside the value range of 1000 to 9999


Response: dfc=error&dfcb=range&dfce=unknown/missing
Range means that the value is outside the value range.
Unknown means not determined but available.
Missing means not specified in the request.

'dfcb' without closing 'dfce'


Response: dfc=error&dfcb=1000&dfce=missing

'dfce' is not a number or is outside the value range of 1000 to 9999


Response: dfc=error&dfcb=1000&dfce=range

'dfce' without incipient 'dfcb'


Response: dfc=error&dfcb=missing&dfce=unknown

‚dfce’ does not equal ‚dfcb’


Response: dfc=error&dfcb=1000&dfce=different
Different means that 'dcfe' is different from 'dfcb' after decryption.

Response of the Web Server


The field content of the request is deciphered successively using the RC4 stream cipher. The field
content of the response is regarded as part of the overall data stream and is ciphered again with the
current status of the stream cipher after decryption. Only exception is the first field value of 'dfcb'. It
is sent back exactly like in the request.
To the response, 'dfce' must be added as last encrypted field. The value of 'dfce' must equal the
value of 'dfcb'.

Activation via Script


The script must use the known "plaintext" password, not the encrypted one generated at the Studio.
See the example-php at the product DVD: "dfanalyser.php“.
For further information see the DLL description on the product DVD under: DVD\\MasterIV-
Serie\Datafox Geräte\Datafox Software MasterIV-04.02.04_Release\Kommunikationsmodul
DFComDLL 04.02.04 (Windows, Linux)

Guide parameterization and integration page 28 date: 30.09.2022 V 1.19


8. http Level 0 with service connection

This type of communication combines the advantages of fast data transfer via HTTP with the full
access to the data acquisition system through the integration of the DLL "Active mode".

Concept of switching between HTTP and Active Mode:

The data transmission will initially run trough HTTP.


Shall now master data such as personal lists, orders or article master are transmitted to the termi-
nal, a maintenance connection is requested from the server.

This is done through the response of the web server.

example: „status=ok&checksum=2120&service=1“

The terminal now interrupts the transmission of data via HTTP and builds automatically a connec-
tion to the DLL (see Active mode). Now Master Data, Setup, etc. can be transferred.

Since the requirement of a service connection is possible only in connection with the response to
transmitted data, you have the option to cyclically send an "Alive" data set.
This makes sense in any case to monitor from the application which devices are online..

After closing the service connection, the device sends the data captured immediately via HTTP. The
possibly incurred in the meantime data are kept in the devices memory.

Guide parameterization and integration page 29 date: 30.09.2022 V 1.19


9. http Level 1
9.1. Requirements
Required for data transfer via http Level 1:
Hardware V4:
- Device with TCP/IP (LAN / WLAN) or mobile radio
- min. Firmware 04.03.10. XX
Software:
- Server must accept an http request and give an active response
- Server must provide master data such as personnel lists or order lists for downloading

Basically, the same schematic structure applies as for http Level 0.

A detailed description of your development can be found here: Link:


https://www.datafox.de/d67/unternehmen/downloads/software/master4-v4/datafox-sdk-http.zip

9.2. Changes between Level 0 and Level 1 concerning Request and Response

9.2.1. The following changes have been made to level 0 in the request:
 First field sent is ‘df_api=1’ always. This field is unencrypted even for active encryption re-
quests.
 The table parameter is now ‘df_table’ after naming scheme.
 All data fields are now starting after the naming scheme with ‘df_col_’.
 In fields of the type "Date and Time" the date and time are separated using a ‘T’ rather than
‘_’.
 The checksum parameter is omitted completely.
 With active encryption parameters ‘dfcb’ and ‘dfce’ are sent as ‘df_cb’ and ‘df_ce’ reflecting
the new naming scheme.

9.2.2. The following changes have been made to level 0 in the response:
 The parameters ‘status’ and ‘checksum’ are completely eliminated.
 As first field ‘df_api=1’ has to be sent always. This field must be transmitted unencrypted
even if encryption is active.
 All existing parameters are prefixed with ‘df_’ and – if necessary – adjusted to the currently
common terms.
 With an active encryption parameters ‘dfc’, ‘dfcb’ and ‘dfce’ change to ‘df_c’, ‘df_cb’ and
‘df_ce’ following the new naming scheme.
 At the end of the server’s reply, no Carriage Return/Linefeed has to be sent. Should you
send Carriage Return/Linefeed at the end of the message, these characters are removed si-
lently. If you need CR/LF inside a message, they have to be encoded as following:
1. All characters other than letters, digits, - (Minus), . (Dot), _ (Underscore) and ~ (Tilde)
have to be encoded as %xx, where xx is the hexadecimal representation of the ASCII
code (See RFC 3986, sections 2.3 and 2.4)

Guide parameterization and integration page 30 date: 30.09.2022 V 1.19


9.2.3. Request

Request from the client to the server.

9.2.4. Method: GET

For communication via http level 1, Datafox has developed a specific context that applies only to
Datafox devices.
The GET method is used for http communication.
The context now offers extensive possibilities for exchanging data quickly and conveniently with Da-
tafox devices.

Function overview via GET:

Parameter name Meaning

df_table Name of data set description


df_record_state online / offline state of the records
Name of the data field and value.
df_col_{Feldname}
Entsprechend der Gerätekonfiguration „Setup“.

Guide parameterization and integration page 31 date: 30.09.2022 V 1.19


9.2.5. Response
The server's response to the client.
Each dataset from a Datafox device must be acknowledged by the server.
The confirmation is carried out with:
df_api=1 und HTTP–Result „200 OK“

9.2.5.1. Optional parameter specifications for the response

Instruction Name Meaning

df_time=2016-11-17T12:13:14 Set the date and time on the device.


df_beep=1 (1-11) OK signal / generate beep on the device
Connect to the DLL. Also possible with the DatafoxStudioIV.
df_service=1,www.datafox.de,10047
Specification of IP/URL and port possible.
df_var=setup.1,wert Change the value of a global variable in the setup.
df_ek=name Trigger an action in the device. Start an input chain in signal
processing.
df_msg=This\ris\ra\rMessage,5,1,0 Send a text message to the display.
Defines the icon to be used when showing a message in the
df_msg_icon=2 device. The icon is taken from the design and associate to
an input sequence (F2 in this example)
Defines the colour of a device’s backlight – for a certain peri-
df_backlight=0,5,255,255,0,192
od of time as a RGBW value.
df_info_msg=Info\rMessage,0 Defines the text of an info message.
AC = access control.
df_ac2=010,1,10,20,5
Trigger access control actions.
df_custom_msg_ac2=010,1,1,0,Hell Sends a message to a device that is connect to the access
o%20World control bus.
Acknowledges an action of the pre-checked access control.
df_ao_ac2=0,1234

Simulates a clocking performed at an access control RFID


df_trigger_ac2=1,011,6543210,0
reader.
Instructs the device to send the value of a system variable.
df_kvp=var,ID
The value is sent as a key-value-pair to the server.
Defines the state of a relay for given period of time that is not
df_set_relay=2,close,5
handled by the access control module.
Changes the state of a relay for a given period of time. The
df_toggle_relay=2,5
relay may not be handled by the access control module.
df_load_file=/path/on/server Instructs the device to download a file from the server.
df_send_file=/logs/,syslog,0 Instructs the device to upload a file to the server.

Guide parameterization and integration page 32 date: 30.09.2022 V 1.19


Instruction Name Meaning

df_remove_file=root:datafox.cert Instructs the device to delete a specific file.


df_remove_finger=1980,all Remove fingers from a fingerprint sensor.
df_setup_list=Personal,/path/to/list.t
Give the device a new list of personnel, for example.
xt
df_ac2_list=Identification,/path/to/list
Give the device a new access control list.
.txt
Counts the number of entries within a list stored on the de-
df_table_count=list.PID
vice.
Selects on or more entries from a list and uploads them to
df_table_select=list.PID,/upload/for
the server.
m,Unit=Development,PID=5

df_table_append=list.PID,9999,,Visit
Appends a record to a list stored on the device.
or,
df_table_update=list.PID,,,Unit= Changes values within a list stored on the device.
df_table_delete=list.PID,Unit=Devel
Removes rows from a list stored on the device.
opment

Function in work,
Not yet usable.

Guide parameterization and integration page 33 date: 30.09.2022 V 1.19


9.2.6. Encryption

The data fields of the data set can be encrypted using a stream cipher RC4. The field contents are
then transferred to their hexadecimal representation.

parameter name importance

The parameter specifies that all these fields until and including
df_ce have encrypted field contents. The value of df_cb contains the
df_cb
four-digit (1000-9999) public key of the applicable password for the
stream cipher.
The parameter indicates that all the following fields are not encrypt-
df_ce ed any more. If the value is decrypted correctly it must match the
value of df_cb.

9.2.6.1. Illustrate the GET request

In plain text (unencrypted) and encrypted:

Plaintext request
df_api=1&df_record_state=1&df_table=Booking&df_col_sn=2042&df_col_recordtype=1&df_col_b
adge=3974679390&df_col_timestamp=2017-11-22T08:23:39&df_col_status=online
Plaintext Reply
df_api=1&df_time=2017-11-22T08:24:00
Encrypted request
df_api=1&df_cb=6102&df_record_state=CC&df_table=66E9B37516AA8C&df_col_sn=0BDC8F79
&df_col_recordtype=AB&df_col_badge=AF9B3A929994A5BD7D88&df_col_timestamp=B237B8
CA4FA80FD563359C3EE70FE7FC99AF60&df_col_status=9BACFC1E5E0B&df_ce=A344D33B
encrypted response
df_api=1&df_cb=6102&df_time=e1ba6575855619c4d634f7865c01c4b2bc2ec138670ac2&df_ce=
a414ebd6

9.2.6.2. Encryption detection

To see whether the data fields are sent encrypted, the initial encryption is with ‘df_cb’ (Datafox Crypt
Begin) in and with ‘df_ce’ (Datafox crypt end) in the end. ‘df_cb’ the first field in the request and
‘df_ce’ the last field in the request is.

The value of the field ‘df_cb’, itself is transmitted in plain text and is ‘public key’. It is a random num-
ber between 1000 and 9999. The value must be used in conjunction with the communication pass-
word for the encryption and decryption.

Guide parameterization and integration page 34 date: 30.09.2022 V 1.19


9.3. https Communication
9.3.1. Requirements
Requirement for using an SSL certificate (https):
Hardware V4:
- Device with TCP/IP (LAN / WLAN) or mobile radio
Minimum firmware 04.03.11. XX (currently usable as prototype firmware)
Software:
- Server must accept an https request and give an active response

A detailed description of your development can be found here:Link:


https://www.datafox.de/d67/unternehmen/downloads/software/master4-v4/datafox-sdk-http.zip

9.3.2. Elements of the https infrastructure


Like http, https is a client-server protocol. The client establishes a connection to the port of the https
server via TCP/IP, the data stream is encrypted to protect it against listeners.

Both asymmetric encryption (negotiation of the connection) in the form of a server certificate and
symmetric encryption for (later) data exchange are used.

9.3.3. Use of encryption / certificates

Several certificates can be stored in the Datafox devices for communication.


You can use a certificate signed by Datafox or your own certificate.

The firmware rejects the use of the encryption methods according to specification TLS 1.0, which
are no longer considered to be up-to-date (because they are unsafe). Only procedures introduced
as of TLS 1.1 are accepted.

Certificates are transferred with the DatafoxStudioIV


The menu item is available as of StudioIV version 04.03.11. XX.
You will find them under: "Configuration>Transfer Certificates".

Guide parameterization and integration page 35 date: 30.09.2022 V 1.19


10. Talk

Datafox - Talk enables the exchange of data with Datafox AEIII +, Timeboy and the Master IV - Se-
ries on file and database level. It therefore represents an alternative to communication via DLL and
has the great advantage that no programming is required. Lists and devices can be transferred
manually or by timer settings data can be read. At extra cost calculation a direct access to customer
databases can be provided. Here, the customer determines which database tables and fields are
linked.
Datafox- Talk supports all functions for transmitting data.

10.1. Advantages and disadvantages with Datafox Talk

advantages:
Easy data exchange via file storage or database
Automatic fetching of the data via services
Integrated web server to accept data via http
No programming required
Simple updating of master data

disadvantages:
No access to system variables
No online functionality

Guide parameterization and integration page 36 date: 30.09.2022 V 1.19


10.2. When do I use Talk?

advantages:
• Expanded use possibilities of the devices
• Simplifies commissioning and maintenance
• No programming skills required
• Communication with any application software
• No need to create a special interface
•Data can be run directly into the application

10.3. Overview of the Function Modules Talk

• Free formatting of the output files


• ODBC connection to external databases and XML interfaces
• Special functions possible
• Wireless data transmission with 433 MHz
• Wireless network with multiple access points possible
• Management of radio addresses
• Protocol monitoring only for TimeboyIII

• Data transfer via analogue, ISDN or GSM


modem.

• Data transfer directly to the Talk-data server and Maintenance


Server on Windows
• Data transfer from your web server via a text file with FTP access.
PHP necessary.
• Data transfer from your web server via MySQL database with
access to the database.
• Data transfer from your web server via MySQL database with
access via http

• time control
• Data transmission for all Datafox devices via RS232, RS485 and TCP /
IP
• Storage of read data as an ASCII file, Excel, XML, dBase, Access
• Loading lists and access lists from ASCII files.

Guide parameterization and integration page 37 date: 30.09.2022 V 1.19


10.4. Establishment of Talk

For the establishment of Talk, we recommend a training by Datafox.


Current training dates can be found on our website:
https://www.datafox.de/support/datafox-akademie

The Datafox Talk Manual can be found on the product DVD or on the hompage.
https://www.datafox.de/d67/unternehmen/downloads/software/datafox-talk/datafox-talk-
handbuch.pdf

A quick tour of setting up Datafox Talk.

User interface:

Each Datafox device, data will be ex-


changed with, will be created here.
The type of connection is established,
such as TCP / IP or HTTP Comport.

For each module there is a separate service


that is installed here as needed and can be
started and stopped.

Guide parameterization and integration page 38 date: 30.09.2022 V 1.19


Settings for data export:

Determine where the


data should be export-
ed.

Set the stora-


ge format.

Settings for time control of the service:


Here are all tasks that the service performs time controlled are created.

Create Event List.

Possible events:

Guide parameterization and integration page 39 date: 30.09.2022 V 1.19


11. Anhang
11.1. Information for HTTPS

HTTPS is used for establish-ing encrypted connections


as well as for encrypted transmission of data via LAN,
WLAN or mobile radio.
This document describes the functionality in princi-pal,
gives hints for the im-plementation and back-ground
information on the technologies used.

https://pixabay.com/illustrations/cyber-security-technology-network-3374252/

Datafox Devices implements TLS (Transport Layer security) using the mbed-TLS library. With this implemen-
tation the devices provide TLS 1.1 and TLS 1.2 functionality, TLS 1.3 is not available currently (May 2020).

This document does not analyse if the data transported between Datafox Devices and an OEM application is
with the cost of “cracking” the encryption. This evaluation is left to the reader. However since clocking events
are personal data without a doubt, the GDPR requires protecting these data elements – seldom they are mat-
ter of secrecy.

Establishing an HTTPS communication


HTTPS communication takes two phases:
• During the TLS handshake client and server check the authen-ticity of their corresponding communication
partner. This phase uses the Diffie-Hellmann-Algorithm. After the verifica-tion an encryption key for the ex-
change of data is established. This process takes place whenever a communication is being negotiated.
• During data exchange, all communication is done encryptedly using the previously established key.

During the TLS handshake asymmetric cryptography is used, during data exchange symmetric cryptographic
algorithms are used. Typically RSA (named after Rivest, Shamir and Adleman, who specified the algorithm) or
ECC (Elliptic curve cryptography) are used for the handshake, AES (Advanced encryption standard) for data
exchange. This makes HTTPS a “hybrid cryptographic algo-rithm.”

Asymmetric vs. Symmetric cryptography


Asymmetric algorithms use different keys for encryption and de-cryption – symmetric algorithms use the same
key for encryption and decryption. Using different keys at asymmetric methods allows creating a public and
private part of the key – as required for a “Public key infrastructure” (PKI). Splitting the key typically results in
higher resource consumption of the algorithm (computation time as well as memory) when comparing to
symmetric cryptog-raphy.

Key factors influencing cryptographic security


The security of encrypted data exchange depends on different factors:
• Safety of the algorithm,
• Length of the key,
• Safety of the systems that exchange data,
• Safety of the infrastructure used to exchange data.

Typically not all above mentioned aspects can be influenced by the user. Algorithms are implemented as soft-
or hardware, safety of a server system may be in your hands, that of the client typically is not as well as the
infrastructure used for communication – if it is a non-private network. The key length seems to be the essential
parameter of control.

Guide parameterization and integration page 40 date: 30.09.2022 V 1.19


Comparison of Algorithms
Additionally it has to be considered that different algorithms offer different security. To make algorithms com-
parable they are pro-jected onto an ideal block cipher and the resulting key length (named “Security bits”) of
this cipher is used to compare algo-rithms. Since TLS uses asymmetric as well as symmetric ciphers, the min-
imal security bits of both algorithms is a good figure for the overall security of the hybrid algorithm.

Microchip [2] provides the following comparison for AES, RSA and ECC algorithms, citing the NSA as source.

Symmetrisch Verschlüsselung | Asymmetrisch Verschlüsselung |


Schlüssellänge | Security Bits
Symmetric cipher Asymmetric cipher
112 3DES RSA-2048
128 AES-128 RSA-3072, ECC-256 (prime256v1)
192 AES-192 RSA-7680, ECC-384 (secp384r1)
256 AES-256 RSA-15360, ECC-521 (secp521r1)

The BSI (Germany federal agency for IT safety) gives the following recommendations:
• Until end of 2022 100 security bits shall be sufficient,
• From 2023 on 120 security bits are recommended (BSI TR-02102-1 from 2020-03-24, page 14, see [1])

Using different certificates/keys on a single server


If you require to use different certificates/keys on the same physical server-host (hardware) and to access the
services by a common port, TLS offers SNI as a mechanism comparable to virtual hosts in plain HTTP com-
munication. The TLS handshake offers Server Name Indication (SNI, see [7] and [9]), which is supported by
Datafox Devices. Using SNI the selection of the correct HTTPS server pro-cess (Software) is done already
during the handshake.

Enabling SNI differs between web server implementations. A guide-line how to use SNI with a Microsoft IIS is
available at [8]. Should you be using reverse proxies or load balancers, please ensure that they support SNI –
detailing this here is way beyond the scope of this document. Please consult you network admins as well.

Using SNI you can e.g. associate different TLS certificates/keys to your ERP system and Datafox Devices
using the same server infra-structure. Datafox Devices may use a 2048 bit or 3072 bit key whereas you may
see to tighter security concerns of the ERP system by using a 4096 bit key – if you have the requirement con-
cerning security.

Summary
We recommend to use an ECC-bases certificate with a 256 bit key together with Datafox devices. This is con-
form to the BSI recom-mendation for 2023. Compared to comparable RSA certificates you increase the per-
formance of the devices and need less memory.

Information on creation and usage of RSA- or ECC-based certif-icates are available at [9].

Detailed considerations on symmetric and asymmetric cryp-tography will follow in the appendix.

With SNI you may use cryptography with different key sizes on a single host – if you should require stronger
security for some services. SNI is a standardized method used by many cloud platforms.

Guide parameterization and integration page 41 date: 30.09.2022 V 1.19


Appendix

Standards in use
The cryptography standards TLS 1.1 and TLS 1.2 define a set of ciphers and signature algorithms. These al-
gorithms are subject to cryptographic analysis, which results in aging of the algo-rithms – a method consid-
ered safe 10 years ago may not be safe anymore – due to algorithmic weaknesses or the increase of compu-
tational power available. Thus our devices do not support TLS 1.0 or even older standards SSLv2 and SSLv3
intentionally.

Asymmetric cryptography
Asymmetric cryptography is used during the TLS handshake when authenticating client and server. The key
parts (public and private) are represented as X509.3 certificates. For en-cryption and decryption both key
parts are needed. If one of the parts is unknown the computational requirement is signifi-cantly higher and the
results of decryption will be ambiguous.

The private part of the key is the fragment to be safeguarded. All devices that have access to the private key
can use it to prove their authenticity – a client cannot distinguish servers by cryptographic methods if the serv-
ers are using the same key.

To mitigate the problems that arise from loss of a key, the X509.3 certificate includes a validity period, enables
hierarchic certificates and supports revocation lists. Please be aware that certificates at the top of a certificate
hierarchy have a very long validity period, typically 10 years or more. The “real” server certificate offers a
shorter validity period ranging from 90 days to 2 years typically. Obviously a certificate authority (CA) de-
serves a higher amount of trust than us using key concerning safeguarding keys – as far as the algorithm is
concerned.

TLS authentication is design in a way, so that not all public certificates are needed when verifying authenticity.
The CA’s certificate is sufficient. This makes short validity periods of a server’s certificate bearable at the cli-
ent side since the CA certificates (see above) have a long validity period.

Comparable to checking the server authenticity by the client, the server may check the client authenticity dur-
ing the TLS handshake. For this a so-called client-certificate may be used.

Once authentication is completed, the symmetric cipher algo-rithm and its key are negotiated. Details on the
functionality of the Diffie-Hellmann-Algorithm are described in many places on the World Wide Web, the doc-
uments at [5] seem to be good entry point.

Symmetric cryptography
Typically the AES algorithm is used as symmetric cipher. This algorithm is specified for key lengths of 128,
192 or 256 bits – which seems rather short when comparing it to typical RSA key lengths. Hence the AES al-
gorithm is well studied which led to some non-dramatic weaknesses of the algorithm.

Estimates on necessary computational power for cracking a 128 bit AES key are
• 30 years using an ideal quantum computer (~10 Seconds if the key has only 100 bits)
• 2.15 * 1012 years on hardware currently available (~6000 years for a 100 bit key)
Our sun has an estimated lifetime of 5 * 109 years.

The symmetric encryption is negotiated with every handshake. An HTTPS connection is disconnected by the
infrastructure typically after being idle for 30 seconds. So, cracking the sym-metric channel encryption re-
quires computation resources after each re-negotiation of the communication.

Guide parameterization and integration page 42 date: 30.09.2022 V 1.19


Attack scenarios
Currently no feasible attack on an established AES encrypted channel using current hardware is known, so
attacking TLS focuses on the handshake as well as the algorithms in use. Some of these attacks made it to be
internally renown by now:
• Heartbleed (OpenSSL < 1.0.1g: A client could retrieve data from the server – potentially the server’s key.)
• FREAK (faulty implementation of US export regulation could lead to accepting very short keys for asym
metric cryptography)
• BEAST (TLS < 1.1: Implementation issues of symmetric encryption)

Exploits that may be used over the network are of particular interest – the system attacked is not aware of that
attack typically.

Attacking the Handshake


During attacks on the handshake, either negotiating the algo-rithm or the key to be used may be influenced
(resulting in either weaker symmetric cipher or a key with some “known” bits).

Attacking the Handshake


During attacks on the handshake, either negotiating the algo-rithm or the key to be used may be influenced
(resulting in either weaker symmetric cipher or a key with some “known” bits).

Compromised client or server


If an attacker has access to client or server, it may be possible that the key is retrieved or changed.

Random number generator attack


Many encryption and signature algorithms use “entropy” to harden the algorithm against attacks. Entropy typi-
cally is part of a negotiated key as well. Having a system that does not produce “good” random numbers and
knowing their distribu-tion is helpful when determining the encryption key.

Timing attacks
In many algorithms there is a time difference between checking an incorrect key and checking a correct key.
These deviations may be observed externally and harvested to deduce the proximity of the test key and the
real key.

Attacking the encrypted channel


Attacking an established channel encryption is difficult if the attacker may not influence either side of the
communication. The key space of algorithms used currently is too big to deter-mine the key by guessing
(“brute force”). In addition to the guess work it is necessary to know the content of a transac-tion in order to
determine the right key.

Padding oracle attacks


Many symmetric ciphers are encoding a fixed length of data (“block”). Consequently, a message which has a
length not dividable by the block length will be padded. Some algorithmic implementations have weak padding
algorithms that may be used to have an own message encoded.

Exploiting weaknesses of an algorithm


If an algorithm has weaknesses, these may be exploited when decrypting a message. The AES-128 bit algo-
rithm has weak-nesses that reduce the key space roughly to the billionth part of the original key space – which
is a vast reduction for a brute force attack.

If the algorithm has no additional weaknesses, that allow guessing additional parts of the key, it may still be
put to use. In the case of AES-128 there are still roughly 1030 keys left.

Guide parameterization and integration page 43 date: 30.09.2022 V 1.19


Guessing the key by brute force
Brute force attacks are typically not usable on today’s algo-rithms.

However, [6] details the steps in chronological order that lead to the DES algorithm with a key length of 56 bit
being consid-ered unsecure. A substantial part in this is attributed to in-creased computational power since
1975 which resulted in brute force attacks being feasible when using distributed com-puting.
It is likely that quantum computing – when being available – will lead to a comparable situation with current
cipher algo-rithms.

Key length considerations in PKI


In addition to above mentioned security aspects, that should be considered when exchanging data, the key
length remains the main factor of security.

Today typically RSA and ECC based algorithms are used.

RSA
The BSI recommends using a key with at least 2000 bits. A key of this length is expected to provide reasona-
ble security until end of 2022 (see [1]: BSI TR-02102-1, March 24th 2020)

RSA and the symmetric cipher being used are compared con-cerning the security bits of an equivalent ideal
block cipher. The BSI recommends a key length equivalent to 100 security bits (roughly 1900 bit RSA) to be
used currently, from 2023 the key length should be at least 120 bits (roughly 2800 bit RSA).

Microchip [2] uses the same scale for its recommendations and reaches the same conclusions as the BSI.
The Microchip table shows that a key length increase does not result in a proportional increase in security bits.
To reach the security level of an AES 256 algorithm, a hypothetical RSA key of equivalent strength should
have 15360 bits.

The time estimates for factorizing (“cracking”) a 2048 bit RSA key deviate when checking web, please check
[3] and [4].

The estimates seem to emphasize, that a 2048 bit certificate still has enough security reserves to be safe
against attacks with reasonable effort. BSI sees RSA as a technology on the way to obsolescence and sug-
gests migration towards ECC base algo-rithms.

ECC
Algorithms based on ECC reach a security level comparable to RSA with shorter keys (see [2]). We have ad-
ditionally measured memory consumption while comparing RSA-2048, RSA-3072 and ECC-256 ciphers dur-
ing the TLS handshake and we have seen that ECC-256 consumes
• 6 % less memory than RSA-2048 and
• 22% less memory than RSA-3072.
We came to the conclusion that ECC based cipher’s resource efficiency is worth using the ciphers, despite
RSA is widely considered industry standard. Thus we recommend using ECC.

Guide parameterization and integration page 44 date: 30.09.2022 V 1.19


Quellen Sources
[1] https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Publikationen/TechnischeRichtlinien/TR02102/BSI-TR-02102.html
Germany federal agency for IT safety, Technical Report on Data
BSI TR-02102-1 vom 24.03.2020 Security and Safety, TR-02102-1 issued March 24th 2020

[2] http://ww1.microchip.com/downloads/en/DeviceDoc/Atmel-8951-CryptoAuth-RSA-ECC-Comparison-Embedded-Systems-WhitePaper.pdf
RSA vs ECC Comparison for Embedded Systems, Whitepaper
Vergleich von RSA und ECC für eingebettete Systeme, Whitepaper
[3] https://www.quintessencelabs.com/blog/breaking-rsa-encryption-update-state-art/
Estimates of breaking RSA encryption
Schätzungen zum Knacken eines RSA Schlüssels
[4] https://en.wikipedia.org/wiki/RSA_(cryptosystem)
Description of the RSA algorithm
Beschreibung des RSA Algorithmus
[5] https://www.cloudflare.com/learning/ssl/what-happens-in-a-tls-handshake/
Description of the TLS handshake
Beschreibung der TLS Verbindungsaushandlung
[6] https://de.wikipedia.org/wiki/Data_Encryption_Standard
Beschreibung des Data Encryption Standards (DES) aus 1975
Description of the Data Encryption Standard (DES) from 1975
[7] https://de.wikipedia.org/wiki/Server_Name_Indication
Beschreibung der TLS-Erweiterung SNI
Description of the TLS-Extension SNI
[8] https://docs.microsoft.com/en-us/iis/get-started/whats-new-in-iis-8/iis-80-server-name-indication-sni-ssl-scalability
Erläuterung zur Nutzung von SNI mit dem Microsoft IIS
Explanation for using SNI with a Microsoft IIS
https://www.datafox.de/download/Datafox%20Datenprotokoll%20zur%20HTTP(S)-Kommunikation.pdf
[9]
https://www.datafox.de/download/Datafox%20data%20protocol%20HTTP(S)-communication.pdf
Datafox http/https Protokoll Dokumentation Datafox http/https protocol documentation

Guide parameterization and integration page 45 date: 30.09.2022 V 1.19

You might also like