Datafox guide to parameterization and integration of microcontroller devices V1.19_2022.09.29_EN
Datafox guide to parameterization and integration of microcontroller devices V1.19_2022.09.29_EN
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
System variables
-mobile /digital signals
This connection is important because you do not have access to the individual areas of the system
with every communication technology.
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.
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.
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.
To create an individual discplay design for your device, you need at least the
DatafoxStudioIV 04.03.09.05.
Example Picture:
Example:
2.4.4. Upload images for function buttons of EVO 4.3 / 2.8 / 3.5
With the installation of the DatafoxStudioIV you get several design examples for the devices.
Click on the "Design Examples" button to open them.
1. bookings
2. master data
3. operating +
signal Processing
4. access control
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
6. Collect data
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.
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.
Attention:
AES / CCMP
WEP64 „AES 128“
Authentication Authentication
Open/None (0) Shared/PSK
Shared/PSK (1)
Attention:
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.
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.)
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".
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
Online
Mode
Online All access authori-
zations are decid-
Mode ac- ed directly from
cess the server
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).
An exemplary query of a device serial number in an device connected via TCP / IP using the C pro-
gramming language:
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.
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 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.
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
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.
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
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".
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.
After this you can clear the created key from the .ini file.
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.
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))
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
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.
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".
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.
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.
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.
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'.
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".
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.
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)
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.
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.
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.
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.
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
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.
Both asymmetric encryption (negotiation of the connection) in the form of a server certificate and
symmetric encryption for (later) data exchange are used.
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.
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.
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
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
• 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.
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
User interface:
Possible events:
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.
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.”
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.
Microchip [2] provides the following comparison for AES, RSA and ECC algorithms, citing the NSA as source.
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])
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.
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.
Exploits that may be used over the network are of particular interest – the system attacked is not aware of that
attack typically.
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.
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.
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.
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.
[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