+49 (0) 228 76 76 9854

+49 (0) 228 76 76 9854

Home » Things to know » Secu­rity

Secu­rity

Intro­duc­tion

This article is not speci­fi­cally about secu­rity in NeuroomNet, but, since NeuroomNet is a web-based tool, about the secu­rity of web-based tools in general. In other words, what you should consider opera­ting a system like NeuroomNet secu­rely. We are happy to help you with any ques­tions you may have, but you can get some ideas below about what to consider.

Security issue: Shadow of hand opening a door that is not locked

Secu­rity is a double-edged sword: If the secu­rity is too high, the autho­rized user is so massi­vely hindered in the tasks that accep­tance suffers signi­fi­cantly. But if it is too low, this can lead to very serious conse­quences.
In this respect, the internet is once again both a curse and a bles­sing.
The disse­mi­na­tion of know­ledge is a great strength, but with it, the know­ledge of how to under­mine a system’s secu­rity is also quickly spread. Just as the connec­tion to the internet itself creates the possibility of being able to conve­ni­ently attack a system. On the other hand, certain subsys­tems can be auto­ma­ti­cally kept up to date via the internet and protected from harmful influences.
So if you want to be on the safe side, you have to move with the times and adapt your system to the constantly incre­asing requi­re­ments. There are areas where you can take a brea­ther because the concept already provides a great deal of secu­rity. Other areas adapt auto­ma­ti­cally (if there is access to the internet) and finally, there are areas where you have to regu­larly check whether ever­y­thing is working as intended or react appro­pria­tely.

Encryp­tion

A very successful and long-lasting method is to encrypt the commu­ni­ca­tion between two parties. This means that an atta­cker can neither draw conclu­sions nor get hold of the actual data. Anyone who wants to read this data has to make an enormous effort and has a much easier time, for example, at the end points of the commu­ni­ca­tion, i.e. before it is encrypted/decrypted. Because modern encryp­tion still cannot be cracked in short periods. This means that data can then also be trans­mitted via connec­tions that run over the internet, WLAN, mobile radio, or other publicly visible networks without a guilty consci­ence. And thanks to sophisti­cated mecha­nisms for estab­li­shing the encryp­tion, the user does not even notice this in the best case and is not disturbed by the daily routine. Except when a time limit for rene­wing a secure connec­tion has expired. Because one aspect of secure commu­ni­ca­tion is to renew the under­lying keys so that the lengthy attacks remain unsuc­cessful.

Fire­wall

Another aspect of a long-lasting secu­rity concept is the protec­tion of endpoints by fire­walls. A fire­wall is a secu­rity system that protects a computer network and individual compu­ters from unwanted network access. In short, a modern system must be able to handle encrypted commu­ni­ca­tion and protected networks. If the front door and windows in your house were the fire­wall, then the safe where you store your most valuable things would be the encryp­tion.
Security Icons: Locked screen, Key, Firewall, Maintenance, Thumbs up

Infra­struc­ture

A prere­qui­site for encryp­tion is the possibility of secu­rely sending the keys to legi­ti­mate parti­ci­pants and regu­larly updating them. This is done with the help of so-called certificates. A certi­fi­cate can use a signa­ture to make it credible by whom, for whom, and until when it was issued. A distinc­tion is made between whether a certi­fi­cate must be publicly acces­sible or whether it is used within a closed system. The under­lying tech­no­logy, and thus the secu­rity, is iden­tical for both vari­ants.

Public appli­ca­tion (CA-signed certificates)

For public appli­ca­tions with publicly acces­sible certificates, specia­lized compa­nies are used. These only issue certificates through veri­fied appli­ca­tions that are subject to a fee. Such a certi­fi­cate can then be used for a certain period to secure one’s systems and does not require any special prepa­ra­tion on the compu­ters that already know the issuer.
The dura­tion of such a certi­fi­cate is curr­ently limited to 2 years and is even to be shor­tened to 13 months.
Browser message: This Connection is Untrusted

Internal appli­ca­tion (self-signed certificates)

For internal appli­ca­tions, a self-issued certi­fi­cate can be used. When issuing these certificates, certain limits can be exceeded to reduce the frequency of admi­nis­tra­tive work. For such internal appli­ca­tions, however, an admi­nis­tra­tion of these certificates must first be estab­lished and the issuer must be made known to the parti­ci­pants. This enables the users (or compu­ters) to check whether a certi­fi­cate is (still) valid or to be provided with a new certi­fi­cate. Often both certi­fi­ca­tion systems (internal and external) are used to keep the effort for the users as low as possible or because it is tech­ni­cally neces­sary.
Browser message: This is not a secure connection

Costs and bene­fits

In prin­ciple, ever­y­thing could be handled by public certi­fi­ca­tion autho­ri­ties, but this would cause more costs. It would also be possible to handle ever­y­thing with internal certi­fi­ca­tion autho­ri­ties, but this would cause higher costs for the distri­bu­tion of the certificates in the public space. Apart from that, instal­ling the internal certificates would be an additional effort for the users. Accep­tance would quickly drop to zero.
Tabular comparison: Public-signed certificates, self-signed certificates, without a certificate
Conclu­sion

To ensure that ever­y­thing func­tions as smoothly as possible, a so-called PKI (private key infra­struc­ture) must be estab­lished. This helps with admi­nis­tra­tion and control and can auto­mate individual aspects. There are diffe­rences due to the manu­fac­tu­rers used in each case. It also requires appro­pria­tely trained staff to set it all up and renew it every few years or months, as described above. The regular instal­la­tion of renewed certificates must be ensured, as they cannot replace them­selves.
The more complex a system becomes, the greater the need to set up a sepa­rate certi­fi­ca­tion autho­rity and PKI. The days of “we just plug ever­y­thing into the network switch” are over, because other­wise anyone can connect to the connec­tion, read ever­y­thing along with the login data, and even mani­pu­late it during use (see also man-in-the-middle attack).

Today, it is impos­sible to imagine networks such as the Internet (World Wide Web) and intra­nets (local networks/WLAN) without secu­ring data connec­tions. Almost ever­yone has heard the names of the proto­cols used for protec­tion. Nevert­heless, it is probably not clear to ever­yone what the diffe­rence is between SSL, TLS, and HTTPS and what secu­rity proper­ties these proto­cols have.
Why is a secured data connec­tion useful?
Let’s assume a user wants to control an exhibit in NeuroomNet. When using a secured connec­tion, this user bene­fits from the secu­rity features of encrypted and secured commu­ni­ca­tion. Without encryp­tion, data that is trans­mitted can be read as plain text by anyone who has access to the corre­spon­ding network. With the incre­asing spread of open (i.e. unen­crypted) WLANs, the importance of HTTPS is growing because it allows content to be encrypted regard­less of the network used. Encryp­tion makes it impos­sible for third parties to see, among other things, exactly which pages of a website have been visited.
By using certificates, it can be ensured that no mani­pu­la­tion of the content by third parties is possible during trans­mis­sion and, for example, that no false information about your company is injected into your company website.

The most important proto­cols for secu­ring data connec­tions for opera­tors of websites and web appli­ca­tions

SSL short for Secure Sockets Layer, was desi­gned by Netscape and first released toge­ther with HTTPS in 1994 with their browser. Deve­lo­p­ment continued until version 3.0. Today, vulnerabi­li­ties in SSL are known and the protocol should ther­e­fore no longer be used.

TLS stands for Trans­port Layer Secu­rity and is the successor protocol to SSL 3.0. The first version 1.0 of TLS is a slightly modi­fied variant of the third version of SSL and was stan­dar­dized by the IETF.

The Internet Engi­nee­ring Task Force (IETF) is an orga­niza­tion that deals with the technical deve­lo­p­ment of the Internet to improve its func­tio­ning. Curr­ently, TLS is in version 1.3 and is now also in wide­spread use.
TLS consists of two main compon­ents: TLS Hand­shake and TLS Record. In TLS Hand­shake, secure key exch­ange and authen­ti­ca­tion take place. TLS Record then uses the symme­tric key nego­tiated in TLS Hand­shake for secure data trans­mis­sion — the data is encrypted and trans­mitted with a MAC protected against changes.

MAC stands for Message Authen­ti­ca­tion Code and is used to obtain certainty about the origin of data or messages and to verify their inte­grity. MAC algo­rithms require two input para­me­ters, firstly the data to be protected and secondly a secret key, and calcu­late a checksum from both, the Message Authen­ti­ca­tion Code.
Note: SSL is the more common term nowa­days and often TLS is meant when talking about SSL.
HTTPS stands for Hyper­text Transfer Protocol Secure and is a commu­ni­ca­tion protocol in the network with which data can be trans­mitted in a tap-proof manner. It repres­ents trans­port encryp­tion.
Display in browser: verification source
HTTPS is used to estab­lish confi­den­tia­lity and inte­grity in the commu­ni­ca­tion between the NeuroomNet server and the web browser (client) in the network. HTTPS refers to the use of HTTP via SSL (TLS). The use of HTTPS can be reco­gnized in the browser by the fact that the visited Internet address is preceded by https instead of http. In addi­tion, most modern brow­sers high­light a secure connec­tion visually.
A secure connec­tion is often equated with encryp­tion of the connec­tion. However, SSL/TLS offers additional secu­rity features.
Accor­ding to the original inter­pre­ta­tion, the client browser should first display the certi­fi­cate to the user after selec­ting the HTTPS address. The user then decides whether he trusts the certi­fi­cate for this session, possibly saving it perma­nently, if neces­sary after checking it via the speci­fied links. Other­wise, the HTTPS connec­tion is not estab­lished (“Leave this page” with Firefox or “Click here to leave this page.” with Internet Explorer).

The three main purposes when using SSL/TLS are:

  • Confi­den­tia­lity (through encryp­tion)
  • Data inte­grity
  • Authen­ti­city

These three purposes are explained below.

Confi­den­tia­lity is ensured by encryp­ting the connec­tion. This guaran­tees the user that their access data and, for example, control information cannot be inter­cepted and misused by third parties. Like­wise, it protects all your data in NeuroomNet and thus also forms the basis for compli­ance with the Euro­pean DSGVO.
By guaran­te­eing the inte­grity of the data, it is guaran­teed that mani­pu­la­tion of the control system is not possible. The user would probably not be very happy if, instead of a switch-on command, for example, a delete command was issued, and in such a case the museum would be annoyed about the costs and the effort required for reco­very. It is even more unplea­sant if someone else could take over the entire control system and thus cause great or even exis­ten­ti­ally threa­tening damage.
Authen­ti­city means that the iden­tity of the museum operator is veri­fiable for the user. By ensu­ring the iden­tity of the museum, the user knows exactly who they are commu­ni­ca­ting with. Crimi­nals can exploit a lack of authen­ti­city, for example, by regis­tering domain names that are very similar to a muse­um’s domain and provi­ding a copy of the control under these domains. The poten­tial customer can now be lured to the fake site via a phis­hing email and, if the website is not secured, cannot directly see whether he has landed at the right museum. He may enter his access data and someone else can now go to the right museum unhin­dered.
Authen­ti­ca­tion is used so that both sides of the connec­tion can check the iden­tity of the connec­tion partner when estab­li­shing the commu­ni­ca­tion.

Secured connec­tions in prac­tice

An SSL/TLS certi­fi­cate is required to estab­lish a secure connec­tion. Among other things, the issuer of the certi­fi­cate, the certi­fi­cate holder, and the public key of the certi­fi­cate holder are stored in a certi­fi­cate. Certificates are stored on the server with which a secure connec­tion is to be estab­lished later. To ensure the inte­grity of a certi­fi­cate, it is signed.
A secu­rity certi­fi­cate can be gene­rated and signed by anyone. However, self-signed certificates are not authentic to third parties because no inde­pen­dent insti­tu­tion has veri­fied the iden­tity of the issuer. Most brow­sers, ther­e­fore, display a warning message for websites with self-signed certificates. To verify the authen­ti­city of a website or web appli­ca­tion, a chain of trust is formed between the end user’s browser and the server of the visited website. The browser and opera­ting system manu­fac­tu­rers verify and trust selected orga­niza­tions whose certificates are then stored in the browser or opera­ting system. These orga­niza­tions are also called certi­fi­cate autho­ri­ties. The certi­fi­ca­tion autho­ri­ties can verify the iden­tity of third parties and sign their certificates after veri­fi­ca­tion. To ensure that a minimum stan­dard is main­tained during veri­fi­ca­tion, the orga­niza­tions clas­si­fied as trust­worthy go through a certi­fi­ca­tion process before­hand. Visitors to a website or users of a web appli­ca­tion are then asked to verify that the chain of trust is intact.
There are various levels for veri­fying iden­tity, which differ in the extent of the veri­fi­ca­tion. At the lowest level (class 1), only it is checked whether the appli­cant has the domain noted in the certi­fi­cate. For class 2 certificates, the iden­tity of the appli­cant (individual or company) is veri­fied in more detail, for example with copies of identification docu­ments and company docu­ments. For class 3 certificates, the veri­fi­ca­tion is even more inten­sive and additional docu­ments are required. Class 3 certificates are also referred to as extended vali­da­tion certificates and are charac­te­rized, among other things, by the fact that their use in modern brow­sers is clearly high­lighted.

Recom­men­da­tions for the use of HTTPS

When trans­mit­ting sensi­tive data, the use of an SSL/TLS certi­fi­cate signed by a certi­fi­ca­tion autho­rity is always manda­tory. If only a personal login area is to be protected, a self-signed certi­fi­cate or a certi­fi­cate signed by the hosting provider may be suffi­cient. In the case of self-signed certificates, however, the issuing certi­fi­ca­tion autho­rity must also be stored as trust­worthy for the client so that the browser does not issue warning messages. These settings can be made by IT experts. Setting up a network-wide PKI struc­ture is possible under both Linux and Windows. If there is no suitable IT expert/administrator on site, NeuroomNet can also arrange suitable experts and even take over the main­ten­ance. If neces­sary, these experts clarify the neces­sary docu­ments for obtai­ning external certificates and then also set them up. Internal certificates can have very long terms, while external certificates have to be renewed after just one year.

Notes on authen­ti­city

In theory, authen­ti­city is given when using SSL/TLS certificates, but in prac­tice, there are problems with authen­ti­city and whether one can trust the iden­tity of the operator of a website must be decided on a case-by-case basis. On the one hand, Level 1 certificates are usually issued auto­ma­ti­cally. This means that valid certificates can also be acquired for typo domains, which are often used for phis­hing attacks. On the other hand, authen­ti­city stands and falls with trust in the work of the certi­fi­ca­tion autho­ri­ties. If there is only one certi­fi­ca­tion autho­rity that works care­lessly when checking the authen­ti­city of the appli­cant’s docu­ments or ignores simi­la­ri­ties in names with other compa­nies, it is possible for crimi­nals to have certificates signed for compa­nies with which they have nothing to do.

Certi­fi­cate

An SSL/TLS certi­fi­cate is required to build up a secure connec­tion. Among other things, the issuer of the certi­fi­cate, the certi­fi­cate holder, and the public key of the certi­fi­cate holder are stored in a certi­fi­cate. Certificates are stored on the server with which a secure connec­tion is to be estab­lished later. To ensure the inte­grity of a certi­fi­cate, it is signed.
A secu­rity certi­fi­cate can be gene­rated and signed by anyone. However, self-signed certificates are not authentic for third parties because no inde­pen­dent insti­tu­tion has veri­fied the iden­tity of the issuer. Most brow­sers, ther­e­fore, display a warning message for websites with self-signed certificates. To verify the authen­ti­city of a website or web appli­ca­tion, a chain of trust is formed between the end user’s browser and the server of the visited website. The browser and opera­ting system manu­fac­tu­rers verify and trust selected orga­niza­tions whose certificates are then stored in the browser or opera­ting system. These orga­niza­tions are also called certi­fi­ca­tion autho­ri­ties. The certi­fi­ca­tion autho­ri­ties can verify the iden­tity of third parties and sign their certificates after veri­fi­ca­tion. To ensure that a minimum stan­dard is main­tained during the veri­fi­ca­tion, the orga­niza­tions clas­si­fied as trust­worthy first undergo a certi­fi­ca­tion process. The visitor of a website or user of a web appli­ca­tion is finally checked whether the chain of trust is intact.
There are diffe­rent levels for the veri­fi­ca­tion of iden­tity, which differ in the extent of the veri­fi­ca­tion. At the lowest level (class 1), it is only checked whether the appli­cant has the domain noted in the certi­fi­cate. For class 2 certificates, the iden­tity of the appli­cant (individual or company) is checked in more detail, for example with copies of identification docu­ments and company docu­ments. For class 3 certificates, the veri­fi­ca­tion is even more inten­sive, and further docu­ments are required. Class 3 certificates are also referred to as extended vali­da­tion certificates and are charac­te­rized, among other things, by the fact that their use in modern brow­sers is clearly high­lighted.

Certi­fi­ca­tion Autho­rity (CA)

In information secu­rity, a certi­fi­cate autho­rity (CA) is an orga­niza­tion that issues digital certificates. A digital certi­fi­cate is used to assign a specific public key to a person or orga­niza­tion. This assign­ment is authen­ti­cated by the certi­fi­ca­tion autho­rity by affi­xing its own digital signa­ture to it.
 
Digital certificates contain “keys” and additional information that are used for authen­ti­ca­tion as well as encryp­tion and decryp­tion of confi­den­tial data that is distri­buted via the internet and other networks. Additional information includes, for example, vali­dity periods, refe­rences to certi­fi­cate revo­ca­tion lists, etc., which are included in the certi­fi­cate by the CA.
The task of a certi­fi­ca­tion autho­rity is to issue and verify these digital certificates. It is respon­sible for the provi­sion, allo­ca­tion, and inte­grity assu­rance of the certificates it issues. It thus forms the core of the public key infra­struc­ture.
A certi­fi­ca­tion autho­rity can be a specific company or an insti­tu­tion within a company that has installed its corre­spon­ding server (for example with OpenSSL/enterprise PKI from Micro­soft). Public orga­niza­tions or govern­ment agen­cies can also serve as a certi­fi­ca­tion autho­rity, e.g. in Germany the Federal Network Agency.
In Germany, additional, legally defined requi­re­ments must be met for the issu­ance of advanced elec­tronic certificates accor­ding to § 2 number 2 Signa­ture Act (SigG) or for quali­fied elec­tronic signa­tures accor­ding to § 2 number 3 Signa­ture Act. In parti­cular, the issuers of the certificates are subject to super­vi­sion by the Federal Network Agency to ensure the relia­bi­lity and inte­grity of these certificates in legal tran­sac­tions. For example, the appli­cant for such a signa­ture must perso­nally iden­tify himself to an approved body through his iden­tity card so that such an elec­tronic certi­fi­cate can be issued to him. The data centers operated by the issuers must be parti­cu­larly secure and thus meet high-secu­rity requi­re­ments.

PKI

PKI stands for Public-Key-Infra­struc­ture and in cryp­to­logy refers to a system that can issue, distri­bute and verify digital certificates. The certificates issued within a PKI are used to secure computer-based commu­ni­ca­tion.
Today’s secu­rity in compa­nies relies on multi-level systems so that the highest certi­fi­ca­tion autho­rity and its private key cannot be compro­mised (i.e. read out and misused by crooks or mali­cious people).
https://en.wikipedia.org/wiki/Public_key_infrastructure

Key (Cryp­to­logy)

In cryp­to­logy, a key is information that para­me­ter­izes a cryp­to­gra­phic algo­rithm and thus controls it.
In modern, computer-based symme­tric and also asym­me­tric proce­dures, the key is a bit sequence.
The key is the central compo­nent for decryp­ting a cipher­text and thus obtai­ning the plain­text.
Diagram: Secret text decrypted with secret key to plain text

Key for symme­trical methods

In symme­trical proce­dures, i.e. in all clas­sical methods of cryp­to­graphy and also in modern algo­rithms such as the Data Encryp­tion Stan­dard (DES) or its successor, the Advanced Encryp­tion Stan­dard (AES), both commu­ni­ca­tion part­ners use the same (secret) key for both encryp­tion and decryp­tion. While clas­sical methods, in which the text must be encrypted (i.e. encrypted and/or decrypted) by hand, almost always use a pass­word as the key, the key in modern, i.e. computer-based, symme­trical methods usually consists of a bit sequence.
The secu­rity of a proce­dure depends not only on the algo­rithm itself but also on the key length. If an attack is found against a proce­dure that is more effi­cient than the brute force method, i.e. trying out all possible keys, the proce­dure is considered broken. The key length ther­e­fore directly indi­cates the secu­rity level of a secure proce­dure.

The key to asym­me­trical methods

Asym­me­tric methods, such as the RSA cryp­to­system, use key pairs consis­ting of a public key and a private key.
The public key is not secret, it is supposed to be known to other users, for example by distri­bu­tion via key servers or certi­fi­ca­tion autho­ri­ties. It can be used to perform public opera­tions, i.e., to encrypt messages or verify digital signa­tures. It is important that a public key can be clearly assi­gned to a user or company. If this is not the case, for example, if a message is encrypted with the public key of another user, that user can read the message even though it was not intended for him. To be able to name keys easily, one uses a finger­print, a short hash value that uniquely iden­ti­fies a key.
To decrypt a cipher­text or to sign a message, the private key is needed. In contrast to symme­tric proce­dures, in which several users share a secret key, in the asym­me­tric proce­dure only one user/company has the private (secret) key. This circum­s­tance is what makes it possible in the first place to assign a signa­ture uniquely to a user/company. It is ther­e­fore funda­mental that the private key cannot be derived from the public key.

Key to Security

For more examples and expl­ana­tions, take a look at our documentation.

To the documentation