Top Five Questions About 6G Technology

As 5G continues to roll out, work is already well underway on its successor. 6G wireless technology brings with it a promise for a better future. Among other goals, 6G technology intends to merge the human, physical, and digital worlds. In doing so, there is a hope that 6G can significantly aid in achieving the UN Sustainable Development Goals.

This article answers some of the most common questions surrounding 6G and provides more insight into the vision for 6G and how it will achieve these critical goals.

1. What is 6G?

In a nutshell, 6G is the sixth generation of the wireless communications standard for cellular networks that will succeed today’s 5G (fifth generation). The research community does not expect 6G technology to replace the previous generations, though. Instead, they will work together to provide solutions that enhance our lives.

While 5G will act as a building block for some aspects of 6G, other aspects need to be new for it to meet the technical demands required to revolutionize the way we connect to the world in a fashion.

The first area of improvement is speed. In theory, 5G can achieve a peak data rate of 20 Gbps even though the highest speeds recorded in tests so far are around 8 Gbps. In 6G, as we move to higher frequencies – above 100 GHz – the goal peak data rate will be 1,000 Gbps (1 Tbps), enabling use cases like volumetric video and enhanced virtual reality experiences.

In fact, we have already demonstrated an over-the-air transmission at 310 GHz with speeds topping 150 Gbps.

In addition to speed, 6G technology will add another crucial advantage: extremely low latency. That means a minimal delay in communications, which will play a pivotal role in unleashing the internet of things (IoT) and industrial applications.

6G technology will enable tomorrow’s IoT through enhanced connectivity. Today’s 5G can handle one million devices connected simultaneously per square kilometer (or 0.38 square miles), but 6G will make that figure jump up to 10 million.

But 6G will be much more than just faster data rates and lower latency. Below we discuss some of the new technologies that will shape the next generation of wireless communications.

2. Who will use 6G technology and what are the use cases?

We began to see the shift to more machine-to-machine communication in 5G, and 6G looks to take this to the next level. While people will be end users for 6G, so will more and more of our devices. This shift will affect daily life as well as businesses and entire industries in a transformational way.

Beyond faster browsing for the end user, we can expect immersive and haptic experiences to enhance human communications. Ericsson, for example, foresees the emergence of the “internet of senses,” the possibility to feel sensations like a scent or a flavor digitally. According to one Next Generation Mobile Networks Alliance (NGMN) report, holographic telepresence and volumetric video – think of it as video in 3D – will also be a use case. This is all so that virtual, mixed, and augmented reality could be part of our everyday lives.

However, 6G technology will likely have a bigger impact on business and industry – benefiting us, the end users, as a result. With the ability to handle millions of connections simultaneously, machines will have the power to perform tasks they cannot do today.

The NGMN report anticipates that 6G networks will enable hyper-accurate localization and tracking. This could bring advancements like allowing drones and robots to deliver goods and manage manufacturing plants, improving digital health care and remote health monitoring, and enhancing the use of digital twins.

Digital twin development will be an interesting use case to keep an eye on. It is an important tool that certain industries can use to find the best ways to fix a problem in plants or specific machines – but that is just the tip of the iceberg. Imagine if you could create a digital twin of an entire city and perform tests on the replica to assess which solutions would work best for problems like traffic management. Already in Singapore, the government is working to build a 3D city model that will enable a smart city in the future.

3. What do we need to achieve 6G?

New horizons ask for new technology. It is true that 6G will greatly benefit from 5G in areas such as edge computing, artificial intelligence (AI), machine learning (ML), network slicing, and others. At the same time, we need changes to match new technical requirements.

The most sensible demand is understanding how to work in the sub terahertz frequency. While 5G needs to operate in the millimeter wave (mmWave) bands of 24.25 GHz to 52.6 GHz to achieve its full potential, the next generation of mobile connectivity will likely move to frequencies above 100 GHz in the ranges called sub-terahertz and possibly as high as true terahertz.

Why does this matter? Because as we go up in frequency, the wave behaves in a different way. Before 5G, cellular communications used only spectrum below 6GHz, and these signals can travel up to 10 miles. As we go up into the mmWave frequency band, the range is dramatically reduced to around 1,000 feet. With sub THz signals like those being proposed for 6G, the distance the waves can travel tends to be smaller – think 10s to 100s of feet not 1000s.

That said, we can maximize the signal propagation and range by using new types of antennas. An antenna’s size is proportional to the signal wavelength, so as the frequency gets higher and the wavelength gets shorter, antennas are small enough to be deployed in a large number. In addition, this equipment uses a technique known as beamforming – directing the signal toward one specific receiver instead of radiating out in all directions like the omnidirectional antennas commonly used prior to LTE.

Another area of interest is designing 6G networks for AI and ML. 5G networks are starting to look at adding AI and ML to existing networks, but with 6G we have the opportunity to build networks from the ground up that are designed to work natively with these technologies.

According to one International Telecommunication Union (ITU) report, the world will generate over 5,000 exabytes of data per month by 2030. Or 5 billion terabytes a month. With so many people and devices connected, we will have to rely on AI and ML to perform tasks such as managing data traffic, allowing smart industrial machines to make real-time decisions and use resources efficiently, among other things.

Another challenge 6G aims to tackle is security – how to ensure the data is safe and that only authorized people can have access to it – and solutions to make systems foresee complex attacks automatically.

One last technical demand is virtualization. As 5G evolves, we will start to move to the virtual environment. Open RAN (O-RAN) architectures are moving more processing and functionality into the cloud today. Solutions like edge computing will be more and more common in the future.

4. Will 6G technology be sustainable?

Sustainability is at the core of every conversation in the telecommunications sector today. It is true that as we advance 5G and come closer to 6G, humans and machines will consume increasing data. Just to give you an idea of our carbon footprint in the digital world, one simple email is responsible for 4 grams of carbon dioxide in the atmosphere.

However, 6G technology is expected to help humans improve sustainability in a wide array of applications. One example is by optimizing the use of natural resources in farms. Using real-time data, 6G will also enable smart vehicle routing, which will cut carbon emissions, and better energy distribution, which will increase efficiency.

Also, researchers are putting sustainability at the center of their 6G projects. Components like semiconductors using new materials should decrease power consumption. Ultimately, we expect the next generation of mobile connectivity to help achieve the United Nations’ Sustainable Development Goals.

5. When will 6G be available?

The industry consensus is that the first 3rd Generation Partnership Project (3GPP) standards release to include 6G will be completed in 2030. Early versions of 6G technologies could be demonstrated in trials as early as 2028, repeating the 10-year cycle we saw in previous generations. That is the vision made public by the Next G Alliance, a North American initiative of which Keysight is a founding member, to foster 6G development in the United States and Canada.

Before launching the next generation of mobile connectivity into the market, international bodies discuss technical specifications to allow for interoperability. This means, for example, making sure that your phone will work everywhere in the world.

The ITU and the 3GPP are among the most well-known standardization bodies and hold working groups to assess research on 6G globally. Federal agencies also play a significant role, regulating and granting spectrum for research and deployment.

Amid all this, technology development is another aspect to keep in mind. Many 6G capabilities demand new solutions that often use nontraditional materials and approaches. The process of getting these solutions in place will take time.

The good news? The telecommunications sector is making fast progress toward the next G.

Here at Keysight, for instance, we are leveraging our proven track record of collaboration in 5G and Open RAN to pioneer solutions needed to create the foundation of 6G. We partner with market leaders to advance testing and measurement for emerging 6G technologies. Every week, we come across a piece of news informing that a company or a university has made a groundbreaking discovery.

The most exciting thing is that we get an inch closer to 6G every day. Tomorrow’s internet is being built today. Join us in this journey; it is just the beginning.

Learn more about the latest advancements in 6G research.

View additional multimedia and more ESG storytelling from Keysight Technologies on 3blmedia.com.

SOURCE: Keysight Technologies – https://www.accesswire.com/717630/Top-Five-Questions-About-6G-Technology – 28 09 22

We need to steer 6G toward something useful

The economics of the market will not support widespread deployment of networks at 100 GHz, due to multiple problems.

Two years ago, talking about 6G was a joke. Not anymore. Now that 5G base stations are rolling out in production, the advanced R&D teams of 100 companies are turning their collective attention to “what comes next.”

In every generation so far, the engineers have led the process, driving toward faster data rates and higher spectral efficiency with each step. Extrapolating the trend of the past 30 years, university professors now are testing ever-higher frequency bands, and dreaming about mobile links at speeds in the Tbps range. This is a mistake.

From 1990 to 2020, the speed-driven approach matched up with market requirements pretty well because we had spectrum that was able to propagate well and penetrate indoors. Now things are different.    

Terabit links are a great idea, but there’s a problem if you think that this is the next “G.” The economics of the market will not support widespread deployment of networks at 100 GHz, due to multiple problems:

• Radio signals above 90 GHz don’t penetrate any barriers, including walls, windows, or the windshield of your car. An access point in one room won’t even work for the adjacent room.
• Reflections are not predictable with the small wavelength of signals at 90+ GHz. Operators are trying to use reflections for NLOS 28 GHz and finding that the connection is not stable, because tiny changes due to temperature or moisture can change the angles of a narrow beam’s reflection.
• Propagation in the high frequency bands doesn’t allow radio signals to travel very far. The air itself absorbs energy, leaving us with very short range for the envisioned 6G networks.

The above list of problems are not simply engineering challenges to overcome… they’re basic physics. Don’t fight against God.

When you’re confronted by a roadblock, it can be useful to stop and think: What’s my destination anyway? In this case, it’s increasingly clear that pure speed is not the goal anymore. Nobody really needs terabit speed to their mobile phone. We have mobile networks that can run as high as 2 Gbps today, but almost nobody uses an app that requires more than 50 Mbps. 

Four years ago, I started to say that speed doesn’t matter anymore. People told me that “apps that use gigabit data will come along.” But hey, here we are with nationwide 5G networks and no app is even close to using the peak speed. When nationwide 4G networks were deployed, Uber and Google Maps had already been on the market for three years or more. Times change.

So, chasing faster speed is not a perfect match with the market need. The unsolved problem in the mobile market is about how to deliver mobile data capacity where the people are, not how to deliver faster data to a few line-of-sight locations.  

Instead, I propose a different direction for the thrust of 6G. We should focus our 6G attention on TV white spaces, land-mobile radio bands, radionavigation bands, military bands, and other spectrum below 6 GHz. We have already demonstrated that shared spectrum can work great. Cognitive radios for LAA and CBRS can sense the presence of other radio transmitters and adjust their parameters. Let’s apply these cognitive radio techniques in areas where the spectrum is only lightly utilized, and take advantage of spare channels, coverage holes, and slack time on existing radio services.

Our calculations indicate that below 6 GHz, as much as 3.5 GHz of spectrum is used in ways that leave gaps in either time, frequency, or location. Valuable low-band spectrum is devoted to radio and television broadcasts, which are phasing out in the age of podcasts. As much as 400-500 MHz is devoted to “radionavigation,” which is essentially obsolete in the age of GPS. 

I agree, some of these radionavigation aids are important. For example, at 4.2 GHz every aircraft uses a radar to measure its height above the ground. Let’s leave that band alone, okay? But many other navigation aids are no longer necessary, or could be operated at a 10% duty cycle without anybody getting lost.

Even if the industry can only harvest 30% of the available spectrum below 6 GHz, we could extract another 1100 MHz of spectrum for true mobile communications. That’s double the available mobile spectrum today. (This calculation is for the crowded American market. In other markets we believe the available spectrum would be even richer.)

To me, 1100 MHz of low-band mobile spectrum is far more valuable than 100 GHz of spectrum in the high millimeter-wave bands. If we’re going to spend eight years on blue-sky R&D, let’s focus the effort on something really useful.

Source: https://www.fiercewireless.com/wireless/industry-voices-madden-we-need-to-steer-6g-toward-something-useful – 20 10 20

Detecting Cyber Intrusions in Substation Networks

Multiple layers are necessary to ensure the cybersecurity of substations. Cryptography allows authentication of devices, but not all attacks can be prevented with these measures. Firewalls and “air gaps” can be circumvented through existing remote access tunnels, or through maintenance, computers directly attached to IEDs or the station bus. Therefore, measures are needed to detect threats in the substation to enable quick response and to minimize consequences.

This article will describe the security requirements of IEC 61850 substations and the different approaches for detecting threats in these networks. Subsequently, an approach specifically developed for the IEC 61850 station and process bus will be described.

Attack vectors of a substation

Let us define a cyber attack on a substation as an event where an adversary modifies, degrades, or disables a service of at least one protection, automation, or control device within the substation. Looking at Figure 1, a typical substation can be attacked through all paths marked with a number. An attacker could enter through the control center connection (1), as happened in one of the cyber-attacks in Ukraine, where the firmware of gateway devices was modified (causing their destruction). Another entry point is through engineering PCs (2) connected to substation equipment. When a protection engineer connects their PC to a relay to modify (protection) settings, malware on the PC could, in turn, install malware on the relay in a comparable way to what happened with PLCs in the Stuxnet cyber attack. Laptops used for testing the IEC 61850 system are often directly connected to the station bus which is also a potential way to infect IEDs (3). For this reason, new IEC 61850 testing tools are available which provide a cyber-secure separation between the Test PC and the substation network. This leaves the testing device itself (4) as a potential entry path. Because of this, it is important that test set vendors invest in hardening their devices to make sure that this entry path is not feasible for an attacker to exploit.

The storage of settings (2a) and test documents (3a) could also be a source. This storage server thus also belongs to the critical perimeter. Therefore, it also makes sense to introduce a separate, isolated and protected data management solution for such data.

 

OMICRON

Fig. 1: Attack vectors of a substation.

Security and IEC 61850
A frequent question about cybersecurity in IEC 61850 substations is: “What happens if an attacker injects a trip GOOSE into the station bus – how can I prevent that?” For this, we should not focus on the attacker having physical access to the substation network. This situation is also possible through other measures: an infected engineering or testing PC connected to the station bus, or even that an infected IED could start injecting GOOSE. In this context, the status and sequence numbers in the GOOSE message are quite often presented as GOOSE “security mechanisms”. However, in 2019, such measures should merely be called “safety mechanisms”, because any adversary can listen to the current status and sequence number and inject suitable values. Also, the source MAC address of the GOOSE packet can be spoofed easily by the attacker. The IED receiving the GOOSE has no other option than to react on the first GOOSE received with correct source MAC and correct status/sequence number. The same of course applies to the sample counter in sampled values. The only real measure to prevent such injection attacks is by ensuring the authenticity and integrity of the message using authentication codes at the end of the GOOSE message, as standardized by IEC 62351-6. With this measure, the sending IED is clearly identified and it becomes impossible to manipulate the GOOSE message content. Note that it is not necessary to encrypt the message to get these features. To deliver and maintain these authentication keys for each IED, a key management infrastructure is needed inside the substation. Because of this, these GOOSE security mechanisms have not gained widespread use, yet – but they will. The same applies to MMS and Role-based access control.

Encryption

Encryption has not been mentioned, though it is often seen as the silver bullet for security. The IEC 62351 standard also provides encryption for GOOSE and MMS. However, in the substation environment, there are only a few applications imaginable where confidentiality of messages is important. If messages cannot be tampered with (integrity) and the originator can be verified (authentication) – which is fulfilled by using authentication in GOOSE and MMS, it is not necessary to encrypt the messages. One example where encryption could be necessary is if routable GOOSE (R-GOOSE) are transmitted over an unencrypted communication path. Encryption only provides additional CPU load on the IEDs, decreases GOOSE transmission time and impedes testing scenarios, but in most cases doesn’t provide additional security than authentication codes already provide. Encryption also makes a later analysis of traffic recordings difficult and it impedes monitoring approaches such as the ones described below.

Defense in depth
Most IEC 61850 substations built up until now have not implemented IEC 62351. Even in substations where GOOSE and with authentication codes are applied, infected devices in the network could still infect other devices or affect availability by disturbing the communication system. Therefore, most security frameworks recommend the usage of “Intrusion Detection Systems” (IDS), a well-known term from classic IT systems, to detect threats and malicious activity on the network. Such IDS are now becoming more common in the power system domain.

Requirements for IDS in Substations

In an IEC 61850 substation, an IDS would be connected as depicted in the figure on the first page. Mirror ports on all relevant switches forward a copy of all network traffic to the IDS. The IDS inspects all network traffic communicated over these switches. To be able to analyze the most important traffic between the gateway and the IEDs, the IDS should, at a minimum, be connected to the switch next to the gateway and all other critical entry points into the network. The bay-level switches don’t usually need to be covered as typically only multicast traffic (GOOSE, Sampled Values) originates from there. To ensure that all unicast traffic in all network branches is analyzed, it is essential that all switches are mirrored into the IDS, which is not always possible if switch chips integrated into the IEDs are used.

However, IDS from classic IT are not suitable for the substation environment. While classic IT security is concerned with high-performance servers with millions of connections at the same time, substation IT security deals with devices with limited resources, custom operating systems, real-time demands, and specialized redundancy protocols. For example, a “denial-of-service” attack on an IED’s communication service often only requires 10 connections, such as 10 Ethernet packets, to be successful. This is simply because “denial-of-service” scenarios were not considered in the “good old days” when these devices and protocols were developed. Additionally, there are only a small number of known cyber attacks on substations, but even the first occurrence of a new attack could have severe consequences. Thus, a substation IDS must be able to detect attacks without any previous knowledge about what the attack might look like. This is a very different approach than that of a virus scanner, which has a list of virus signatures it looks for.

Learning-based systems
To be able to detect unknown attacks, many vendors use a “learning-phase” approach. Such systems look at frequency and timing of certain protocol markers to attempt to learn the usual behavior of the system. After the learning phase is complete, an alarm will be raised if one of the markers is significantly outside the expected range. This has the effect that false alarms are triggered for everything that did not occur during the learning phase, such as protection events, uncommon switching or automation actions, or routine maintenance and testing. Because these systems don’t understand the semantics of the protocols, the alarm messages are expressed in terms of technical protocol details. Hence, alarms can only be examined by an engineer skilled in IEC 61850 protocol details and familiar with IT network security. The engineer examining the alarm must also know about the operational situation to judge if certain IEC 61850 protocol events correspond to valid behavior. Therefore, a high number of false alarms occur for every substation, all of which require examination by highly skilled personnel. This often leads to alarms being ignored or alarms being discarded without investigation, and ultimately the IDS being switched off.

The Approach
For IEC 61850 substations, the whole automation system, including all devices, their data models, and their communication patterns is described in a standardized format – the SCL. System Configuration Description (SCD) files normally also contain information about primary assets and, for an ever-increasing number of substations, even the single-line diagram is present.

This information allows a different approach to be used for detecting intrusions: The monitoring system can create a full system model of the automation and power system and it can compare each and every packet on the network against the live system model. Even the variables contained in the communicated (GOOSE, MMS, SV) messages can be evaluated against the expectations derived from the system model. This process is possible without the need for a learning phase, just by configuration from SCL. This approach is implemented in the new functional security monitoring system StationGuard.

Functional Security Monitoring
In essence, very detailed functional monitoring is produced to detect cyber threats in the network. Because of the detail level of the verification, it is not only cybersecurity threats like malformed packets and disallowed control actions that are detected, but also communication failures, time synchronization problems, and consequently also (certain) equipment failures. If the single-line diagram is known to the system, and measurement values can be observed in MMS (or even through Sampled Values) communication, the possibilities of what can be verified are endless.

For example, for GOOSE alone there are 33 alarm codes available for things that could go wrong. These range from simple stNum/sqNum glitches (as explained above) to more complex issues, such as too long transmission times. The latter is detected by accurately measuring the difference between the EntryTime timestamp in the message and the arrival time at StationGuard. If this network transmission time is significantly longer than 3 ms for a “protection” GOOSE (referring to IEC 61850-5), it indicates a problem in the network or in the time synchronization.

What is done for MMS communication? From the system model (from the SCL) it is known which Logical Nodes control which primary assets. Thus, it can be distinguished between correct/incorrect, and critical/noncritical actions. Switching a circuit breaker and switching the IEC 61850 test mode use the same sequence in the MMS protocol (select-before-operate), but the effect in the substation is quite different. So, if the Test PC from Figure 1 switches the test mode on a relay this may be a legitimate action during maintenance, but it is most probably not legitimate that the Test PC operates a breaker. There will be a more in-depth look at this example in the following paragraphs.

Developed with PAC engineers
Research on this approach started in 2011. Spin-offs of this concept, the 24/7 functional supervision of SV, GOOSE and PTP time synchronization, have been available in a distributed and hybrid analysis device (OMICRON DANEO 400) since 2015. Triggered by this, we were approached by the Swiss distribution and generation operator CKW. They were familiar with the disadvantages of commercially available IDS and were looking for a more suitable solution for substations and one that is friendlier for protection, automation and control engineers. This led to a cooperation between the PAC engineers of CKW and the development team for our solution. It was intriguing to hear how they planned intrusion detection to be part of their future substation cybersecurity design. Meanwhile, feedback from many other utilities worldwide, as well as some proof-of-concept installations, found its way into our development.

In 2018, one of the first proof-of-concept installations was installed in a 110 kV CKW substation and has been running since then. Figure 2 shows the installation using the mobile hardware platform MBX1 at the bottom of the picture. In this setup, all traffic from the “core” switch was mirrored to StationGuard. This ensures that all the communication from the gateway to and from all IEDs is visible. Because remote maintenance connections also enter through that switch, all this traffic can also be inspected by StationGuard. Since GOOSE communication is multicast, and because the network setup allows it, all GOOSE from the IEDs in the substation bays are also visible to StationGuard.

OMICRON

Figure 2: Installation in CKW 110 kV substationAlert Display
Besides the avoidance of false alarms, it is also of vital importance that the alarm messages delivered are understandable to the engineers who are responsible for the operation of the protection, automation and network functions within the substation. This allows faster reaction times because often these alarms are triggered by engineers working in the substation (or from remote activities). Additionally, this allows security engineers and PAC engineers to collaborate when tracing events within a substation.

Figure 3 shows a screenshot of the graphical alarm display: The alarm is shown as an arrow from the active participant (Test PC) performing the prohibited action, and the “victim” of the action – a bay controller in bay Q01. Figure 4 reveals details about that alarm – a circuit breaker was operated (using an MMS control sequence), which is not allowed for a Test PC.

Figure 3: Graphical alarm display instead of event list. 

Figure 4: Details for Figure 3: Test PC attempting unauthorized control of circuit breaker.

Maintenance Mode
To avoid false alarms, routine testing and maintenance conditions must be included in the substation system model. This means that the testing and engineering equipment, including protection test sets, can be introduced into the system. In Figure 5 we see that maintenance was activated for Bay Q01. Now the Test PC from the example above can do more than before. There will be no alarm if the Test PC controls the IEC 61850 test or simulation mode of IED -Q1 in this bay. However, the same alarm as before will be triggered if the Test PC operates a breaker in that bay, since critical actions like this are not authorized for a Test PC. Of course, if company policies allow such actions, these rules can be modified.

Figure 5. Maintenance mode activated for bay Q01

Configuration
As previously mentioned, no learning phase is required. The detection starts right from the time that the device is powered up and it cannot be turned off – for security reasons. Until the SCD file of the substation is loaded, all IEDs will be detected and presented as unknown devices. Once the SCD file is loaded, the IEDs will be indicated as known devices and the substation structure is assembled into a “zero-line” diagram, as it was introduced with StationScout. The configuration can also be prepared in the office and then installed on-site, one after the other, with fast commissioning. If not all IEDs were engineered into one file (these things happen), then additional IEDs can also be imported one by one. Once the import is done, the user can add roles such as “Test PC”, “Engineering PC”, etc. to any remaining unknown devices.

What happens in case of an alarm?
It is important to note that the StationGuard is purely passive, if an action is “not allowed” it will trigger an alarm. This alarm can be communicated to the Gateway/RTU and control center or to a separate system collecting security alerts – known as A Security Incident Event Management (SIEM) system. StationGuard does not actively react or interfere with the substation. Depending on the chosen hardware variant, user-definable binary outputs are available to be wired directly to the RTU. In this case, the alarm signalization happens without network communication and the alarms can be integrated into the normal SCADA signal list like any other hard-wired signal from the station.

Cybersecurity of the IDS
As we know from b-grade movies, burglars always attack the burglar alarm system first. So what about the security of this alarm system? An important aspect is that a stand-alone, secure hardware is used and not a virtual machine. Both hardware variants of StationGuard, the mobile (MBX1) and the 19”-variant for permanent installation (RBX1), have the same platform hardening. They both have a secure cryptoprocessor chip according to ISO/IEC 11889. This ensures that cryptographic keys are not stored on the flash storage but in a separate chip which is protected against tampering. By installing the OMICRON certificates on this chip during production, a secure, measured boot chain is created. This means that each step in the firmware bootup process verifies the signatures of the next module or driver to load. This makes sure that only software signed by OMICRON can be executed. The storage of the devices is encrypted with a key unique for that hardware and is protected inside the cryptochip. Because nobody (including OMICRON) knows this key, all data on the device will be lost when the hardware is replaced on repair. Many other mechanisms make sure that the processes on the device cannot be attacked or misused, so that the “defense in depth” approach is also applied deep into the software running on the device. Covering all these mechanisms would be a complete topic for another article.

Outlook
Substations provide potential attack vectors for cyber attacks. If an attacker is able to influence one or more substations, this can have severe consequences for the grid. Therefore, effective cybersecurity measures must be implemented, not only in the control centers, but also in substations. For IEC 61850 substations, an approach for intrusion detection is available which provides a small number of false alarms and still low configuration overheads due to the power of the SCL. This system not only detects security threats, but also functional problems of IEC 61850 communication and of the IEDs are detected – which is also helpful in the FAT and SAT phase. Intrusion detection systems that display detected events in the language of protection, automation and control engineers have the advantage that PAC and security engineers can work together to find the cause of events.

Source: https://www.tdworld.com/test-and-measurement/detecting-cyber-intrusions-substation-networks
15 09 19

Antenna Design for 5G Communications

With the rollout of the 5^th generation mobile network around the corner, technology exploration is in full swing. The new 5G requirements (e.g. 1000x increase in capacity, 10x higher data rates, etc.) will create opportunities for diverse new applications, including automotive, healthcare, industrial and gaming. But to make these requirements technically feasible, higher communication frequencies are needed. For example, the 26 and 28 GHz frequency bands have been allocated for Europe and the USA respectively – more than 10x higher than typical 4G frequencies. Other advancement will include carrier aggregation to increase bandwidth and the use of massive MIMO antenna arrays to separate users through beamforming and spatial multiplexing.

Driving Innovation Through Simulation

The combination of these technology developments will create new challenges that impact design methodologies applied to mobile and base station antennas currently. Higher gain antennas will be needed to sustain communications in the millimeter wavelength band due to the increase in propagation losses. While this can be achieved by using multi-element antenna arrays, it comes at the cost of increased design complexity, reduced beamwidth and sophisticated feed circuits.

Simulation will pave the way to innovate these new antenna designs through rigorous optimization and tradeoff analysis. Altair’s FEKO™ is a comprehensive electromagnetic simulation suite ideal for these type of designs: offering MoM, FEM and FDTD solvers for preliminary antenna simulations, and specialized tools for efficient simulation of large array antennas.

Mobile Devices

In a mobile phone, antenna real estate is typically a very limited commodity, and in most cases, a tradeoff between antenna size and performance is made. In the millimeter band the antenna footprint will be much smaller, and optimization of the antenna geometry will ensure the best antenna performance is achieved for the space that is allocated, also for higher order MIMO configurations.

At these frequencies, the mobile device is also tens of wavelengths in size and the antenna integration process now becomes more like an antenna placement problem – an area where FEKO is well known to excel. When considering MIMO strategies, it is also easier to achieve good isolation between the MIMO elements, due to larger spatial separation that can be achieved at higher frequencies. Similarly, it is more straightforward to achieve good pattern diversity strategies.

 

 

Base Station

FEKO’s high performance solvers and specialized toolsets are well suited for the simulation massive MIMO antenna arrays for 5G base stations. During the design of these arrays, a 2×2 subsection can be optimized to achieve good matching, maximize gain and minimize isolation with neighboring elements –a very efficient approach to minimize nearest neighbor coupling. The design can then be extrapolated up to the large array configurations for final analysis. Farming of the optimization tasks enables these multi-variable and multi-goal to be solved in only a few hours. Analysis of the full array geometry can be efficiently solved with FEKO’s FDTD or MLFMM method: while FDTD is extremely efficient (1.5 hrs for 16×16 planar array), MLFMM might also be a good choice depending on the specific antenna geometry.

 

 

The 5G Channel and Network Deployment

The mobile and base station antenna patterns that are simulated in FEKO, can used in WinProp™ for high-level system analysis of the 5G radio network coverage and to determine channel statistics for urban, rural and indoor scenarios.

 

 

WinProp is already extensively used for 4G/LTE network planning. However, the use cases for 5G networks will be even more relevant largely due to the different factors that occur in the millimeter band. These include higher path loss from atmospheric absorption and rainfall, minimal penetration into walls and stronger effects due to surface roughness.

In addition to being able to calculate the angular and delay spread, WinProp also provides a platform to analyze and compare the performance of different MIMO configurations while taking beamforming into account.

 

The Road to 5G

While some of the challenges that lie ahead to meet the 5G requirements may still seem daunting, simulation can already be used today to develop understanding and explore innovative solutions. FEKO offers comprehensive solutions for device and base station antenna design, while WinProp will determine the requirements for successful network deployment.

 

Source: http://innovationintelligence.com/antenna-design-for-5g-communications/

Comparing the mobile data networks of Europe in OpenSignal’s newest report

Today, OpenSignal released its new Global State of Mobile Networks report, our first worldwide report that looks beyond 4G technology to examine the overall mobile data prowess of nearly 100 different countries. While you can see the overall conclusions and analysis in the report itself, we’re also drilling down to specific regions in a short series of blog posts. Today we’re starting with Europe.

The chart below shows how 33 European countries stack up in mobile data performance, plotting combined 3G and 4G availability on the vertical axis and average 3G/4G speed on the horizontal axis.

3G/4G speed vs. 3G/4G availability

Europe does quite well in general in both speed availability, reflecting not only their investments in LTE but the mature state of their LTE infrastructures. Most of them are clustered in the upper central portion of the chart with speeds between 10 and 20 Mbps and high levels of mobile data signal availability. The vast majority of European users can latch onto a 3G or better signal more 80% of the time, according to our data.

Outside of that main cluster, we do see clumps of countries in similar stages of development. We find several Eastern European countries that haven’t quite caught up with the rest of the region in either speed or availability (sometimes both), though Germany falls in the underperforming category as well. Being a former member of the eastern bloc isn’t always indicative of poorer mobile data performance, though. Both Lithuania and Hungary are well to the right of Europe’s main cluster, joining the Nordic states and the Netherlands in an exclusive club of outperformers. These are the rare countries that are able to offer a consistent mobile data connection greater than 20 Mbps.

3G signals are plentiful around the world

3G has definitely taken hold in most countries. On the 95 countries in our sample, 93 of them had 3G or better signal availability more than half the time, while the vast majority had availability greater than 75%, according to our data.

Big differences remain in average consumer data speeds

Though 3G or 4G connections may be the norm, there are some sizable gaps country-to-country in our overall speed metric, which measures the average download performance across all networks. South Korea had the fastest overall speed of 41.3 Mbps, while the slowest average we measured was 2.2 Mbps in Afghanistan.

The dominant connection type is (surprise!) Wifi

We found high levels of mobile Wifi connections both in countries where mobile broadband is ubiquitous and in countries where mobile data infrastructure is more limited. The most mobile-Wifi-hungry country in the world was the Netherlands, where Wifi accounted for 70% of all of the smartphone connections we measured.

LTE development patterns are clearly emerging

When we correlated overall speeds with 3G/4G availability, we found distinct clusters of countries in similar stages of mobile development. Examining 3G and 4G together paints a much clearer picture of a country’s network progress than measuring 4G alone.

Source: http://opensignal.com/reports/2016/08/global-state-of-the-mobile-network/

The End of the Private Enterprise Network

The network is the last thing that IT fully controls within the enterprise and consumes 12-15% of the enterprise technology budget. Compute, storage and applications are moving to the cloud with its elastic, pay for what is used, model. Users are going mobile, working from anywhere. Networking will be the last thing that is moved to the cloud, but this too will happen.

Users get frustrated with the enterprise network because it is slower to work in the office than when they work from home. CIO’s wonder why they pay 20x more for enterprise bandwidth than what they pay as a consumer. Business leaders are also frustrated with the enterprise network because it is slowing down their digital transformation projects.

Enterprise networks are inherently slower, less agile, less secure, and more expensive because of:

1. Backhauling – Sending all Internet destined traffic back to a data center before going out to the Internet. 80% of enterprise branch office traffic is Internet destined and the backhauling is both expensive and slows down cloud based applications. Mobile device managers also backhaul cellular data traffic, causing the same problem.
2. Legacy business models – Buying upfront tons of equipment (routers, firewalls, load balancers, network optimizers, intrusion detection) and signing multi-year contracts with 1-2 network service providers.
3. ACL hell – Access Control Lists are used by network equipment to define on every interface where packets can and cannot go. This manual process can lead to thousands of rules and spirals out of control with no one understanding why a rule put in 3 years ago still applies. Also, routers are not able to report on which ACLs are used. Every network change requires new ACLs, which can break existing applications, making networks very complex and fragile.
4. Perimeter Security – The assumption that a private network is more secure has not proven true as the many hacks that have been published and the greater frequency in which they are occurring. A zero trust model is required to provide end-to-end security.

Software Defined Wide Area Networks (SD-WANs) are a step towards making networks faster, more agile, and lower costs. SD-WANs utilize broadband Internet to the branch office and provide a security stack at the edge of the network to minimize backhauling and cheaper bandwidth than MPLS. SD-WANs use centralized controllers and IPsec or GRE tunnels to create an overlay network to mask the underlying network complexity. This is why the SD-WAN market is going to grow from 500M this year to 6B by 2020.

But, SD-WANs are just a step towards the Next Generation WAN (NG-WAN) which will be managed by cloud providers through Network as a Service (NaaS). Microsoft, Google, and other large Cloud Service Providers (CSPs) are becoming network operators. Gartner reports that 50% of cloud implementations have business impacting problems due to the network. CSPs realize that if they are going to provide a Quality of Experience (QoE) for their applications, that they need to have greater control of connecting their users.

To achieve complete end to end control of business IT computing and incent migration to cloud services, CSPs will offer secure seamless networking solutions to connect from customer on-premises servers to in-cloud-based resources. The next generation networks will leverage broadband Internet connectivity and high speed optical and Ethernet networks that are inter-connected at the carrier neutral collocations where the CSP’s reside. On the premises will be white box switches and wireless local area networks connected to a very intelligent router and security stack that can dynamically establish direct, secure sessions between application services and users.

This can be done at a fraction of the cost because the CSPs already possess significant technical resources in networking and they have different business models than the traditional Network Service Providers (NSPs). CSPs over time will marginalize existing NSPs and shed the complexity, that inhibits broader migration to cloud-based services.

The market for enterprise networking will go through a radical shakeout and will become commoditized. White box/brite box providers that develop the appropriate partnerships will see new opportunities. Winners will include low cost access and transport service providers along with existing and new network equipment providers bold enough to morph into a volume player for a low margin business.

The best lens into the IT future is to watch what start-up companies are doing. These companies do not have any legacy baggage and adopt the latest and greatest technology and solutions. Few start-ups are creating their own private networks. AirBnB and Uber are examples of companies without a private MPLS WAN.

This is a paradigm shift for the enterprise to go to the 1,000 plus fiber networks and Internet Service Providers (ISPs) that the cloud providers use, versus bringing 1-2 NSPs & ISPs into the enterprise.

Source: http://www.talkingpointz.com/the-end-of-the-private-enterprise-network/

5G Network Architecture 5G Network Architecture – A High-Level Perspective

 

Contents

• A Cloud-Native 5G Architecture is Key
• to Enabling Diversified Service Requirements
• 5G Will Enrich the Telecommunication Ecosystem
  • The Driving Force Behind Network Architecture Transformation
  • The Service-Driven 5G Architecture
• End-to-End Network Slicing for Multiple
• Industries Based on One Physical Infrastructure
• Reconstructing the RAN with Cloud
• 1 Multi-Connectivity Is Key to High Speed and Reliability
• 2 MCE
• Cloud-Native New Core Architecture
• 1 Control and User Plane Separation Simplifies the Core Network
• 2 Flexible Network Components Satisfy Various Service Requirements
• 3 Unified Database Management
• Self-Service Agile Operation
• Conclusion:
• Cloud-Native Architecture is the Foundation of 5G Innovation

Download: 5G-Nework-Architecture-Whitepaper-en

LTE Network Architecture

The high-level network architecture of LTE is comprised of following three main components:

• The User Equipment (UE).
• The Evolved UMTS Terrestrial Radio Access Network (E-UTRAN).
• The Evolved Packet Core (EPC).

The evolved packet core communicates with packet data networks in the outside world such as the internet, private corporate networks or the IP multimedia subsystem. The interfaces between the different parts of the system are denoted Uu, S1 and SGi as shown below:

The User Equipment (UE)

The internal architecture of the user equipment for LTE is identical to the one used by UMTS and GSM which is actually a Mobile Equipment (ME). The mobile equipment comprised of the following important modules:

• Mobile Termination (MT) : This handles all the communication functions.
• Terminal Equipment (TE) : This terminates the data streams.
• Universal Integrated Circuit Card (UICC) : This is also known as the SIM card for LTE equipments. It runs an application known as the Universal Subscriber Identity Module (USIM).

A USIM stores user-specific data very similar to 3G SIM card. This keeps information about the user’s phone number, home network identity and security keys etc.

The E-UTRAN (The access network)

The architecture of evolved UMTS Terrestrial Radio Access Network (E-UTRAN) has been illustrated below.
The E-UTRAN handles the radio communications between the mobile and the evolved packet core and just has one component, the evolved base stations, called eNodeB or eNB. Each eNB is a base station that controls the mobiles in one or more cells. The base station that is communicating with a mobile is known as its serving eNB.
LTE Mobile communicates with just one base station and one cell at a time and there are following two main functions supported by eNB:

• The eBN sends and receives radio transmissions to all the mobiles using the analogue and digital signal processing functions of the LTE air interface.
• The eNB controls the low-level operation of all its mobiles, by sending them signalling messages such as handover commands.

Each eBN connects with the EPC by means of the S1 interface and it can also be connected to nearby base stations by the X2 interface, which is mainly used for signalling and packet forwarding during handover.
A home eNB (HeNB) is a base station that has been purchased by a user to provide femtocell coverage within the home. A home eNB belongs to a closed subscriber group (CSG) and can only be accessed by mobiles with a USIM that also belongs to the closed subscriber group.

The Evolved Packet Core (EPC) (The core network)

The architecture of Evolved Packet Core (EPC) has been illustrated below. There are few more components which have not been shown in the diagram to keep it simple. These components are like the Earthquake and Tsunami Warning System (ETWS), the Equipment Identity Register (EIR) and Policy Control and Charging Rules Function (PCRF).
Below is a brief description of each of the components shown in the above architecture:

• The Home Subscriber Server (HSS) component has been carried forward from UMTS and GSM and is a central database that contains information about all the network operator’s subscribers.
• The Packet Data Network (PDN) Gateway (P-GW) communicates with the outside world ie. packet data networks PDN, using SGi interface. Each packet data network is identified by an access point name (APN). The PDN gateway has the same role as the GPRS support node (GGSN) and the serving GPRS support node (SGSN) with UMTS and GSM.
• The serving gateway (S-GW) acts as a router, and forwards data between the base station and the PDN gateway.
• The mobility management entity (MME) controls the high-level operation of the mobile by means of signalling messages and Home Subscriber Server (HSS).
• The Policy Control and Charging Rules Function (PCRF) is a component which is not shown in the above diagram but it is responsible for policy control decision-making, as well as for controlling the flow-based charging functionalities in the Policy Control Enforcement Function (PCEF), which resides in the P-GW.

The interface between the serving and PDN gateways is known as S5/S8. This has two slightly different implementations, namely S5 if the two devices are in the same network, and S8 if they are in different networks.

Functional split between the E-UTRAN and the EPC

Following diagram shows the functional split between the E-UTRAN and the EPC for an LTE network:

2G/3G Versus LTE

Following table compares various important Network Elements & Signaling protocols used in 2G/3G abd LTE.

2G/3G	LTE
GERAN and UTRAN	E-UTRAN
SGSN/PDSN-FA	S-GW
GGSN/PDSN-HA	PDN-GW
HLR/AAA	HSS
VLR	MME
SS7-MAP/ANSI-41/RADIUS	Diameter
DiameterGTPc-v0 and v1	GTPc-v2
MIP	PMIP

Source: http://ershoeb.blogspot.nl/2016/03/lte-network-architecture.html

Cisco Sets Digital Network Architecture as its Platform of the Future

Cisco unveiled its Digital Network Architecture (DNA) for transforming business with the power of analytics driven by programmable networks, cloud applications, open APIs, and virtualization.  The Cisco DNA aims to extend the company’s data center-based, policy-driven Application Centric Infrastructure (ACI) technology throughout the entire network: from campus to branch, wired to wireless, core to edge.

Cisco DNA is built on five guiding principles:

• Virtualize everything to give organizations freedom of choice to run any service anywhere, independent of the underlying platform – physical or virtual, on premise or in the cloud.
• Designed for automation to make networks and services on those networks easy to deploy, manage and maintain – fundamentally changing the approach to network management.
• Pervasive analytics to provide insights on the operation of the network, IT infrastructure and the business – information that only the network can provide.
• Service management delivered from the cloud to unify policy and orchestration across the network – enabling the agility of cloud with the security and control of on premises solutions.
• Open, extensible and programmable at every layer – Integrating Cisco and 3rd party technology, open API’s and a developer platform, to support a rich ecosystem of network-enabled applications.

“The digital network is the platform for digital business,” said Rob Soderbery, SVP for Enterprise Products and Solutions, Cisco.  “Cisco DNA brings together virtualization, automation, analytics, cloud and programmability to build that platform.  The acronym for the Digital Networking Architecture – DNA – isn’t an accident. We’re fundamentally changing the DNA of networking technology.”

The first deliverables of Cisco DNA include:

DNA Automation:  APIC-Enterprise Module (APIC EM) Platform

• APIC-EM Platform:  A new version of Cisco’s enterprise controller has been released. Cisco claims 100+ customer deployments running up to 4000 devices from a single instance.  The company is adding automation software that removes the need for staging for pre-configuration or truck roll-outs to remote locations. The Plug and Play agent sits on Cisco routers and switches and talks directly to the network controller. A new EasyQoS service enables the network to dynamically update network wide QoS settings based on application policy.
• Cisco Intelligent WAN Automation Services: This service automates IWAN deployment and management, providing greater WAN deployment flexibility and allowing IT to quickly configure and deploy a full-service branch office with just 10 clicks.  IWAN automation eliminates configuration tasks for advanced networking features, and automatically enables Cisco best practices, application prioritization, path selection and caching to improve the user experience.
• DNA Virtualization:  Evolved IOS-XE is a network operating system optimized for programmability, controller-based automation, and serviceability. The new OS provides open model-driven APIs for third party application development, software-defined management, application hosting, edge computing and abstraction from the physical infrastructure to enable virtualization.   It supports the Cisco Catalyst 3850/3650, ASR 1000 and ISR 4000 today, and will continue to be expanded across the Enterprise Network portfolio.

  Evolved Cisco IOS XE includes Enterprise Network Function Virtualization (Enterprise NFV) that decouples hardware from software and gives enterprises the freedom of choice to run any feature anywhere. This solution includes the full software stack – virtualization infrastructure software; virtualized network functions (VNFs) like routing, firewall, WAN Optimization, and WLAN Controller; and orchestration services – to enable branch office service virtualization.

• DNA Cloud Service Management:  CMX Cloud provides business insights and personalized engagement using location and presence information from Cisco wireless infrastructure.  With CMX Cloud enterprises can provide easy Wi-Fi onboarding, gain access to aggregate customer behavior data, and improve customer engagement.

Source: http://www.convergedigest.com/2016/03/cisco-sets-digital-network-architecture.html

Things that use Curve25519

Here’s a list of protocols and software that use or support the superfast, super secure Curve25519 ECDH function from Dan Bernstein. Note that Curve25519 ECDH should be referred to as X25519.

You may also be interested in this list of Ed25519 deployment.

This page is divided by Protocols, Networks, Operating Systems, Software, TLS Libraries, Libraries,Miscellaneous, Timeline notes, and Support coming soon.

Protocols

• DNS
  • DNSCurve — encrypted DNS between a resolver and authoritative server
  • DNSCrypt — encrypted DNS between a client and a resolver
• Transport
  • CurveCP — a secure transport protocol
  • QUIC — a secure transport protocol
  • ZeroMQ — a secure transport protocol
  • Nitro — a library for painlessly writing scalable, fast, and secure message-passing network applications
  • lodp — Lightweight Obfuscated Datagram Protocol
  • RAET — (Reliable Asynchronous Event Transport) Protocol
  • SSH, thanks to the non-standard curve25519-sha256@libssh.org key exchange from the libssh team, adopted by OpenSSH and tinyssh
• TLS
  • Nettle is the crypto library underneath GnuTLS
  • BoringSSL from Google
  • Other libraries are coming!
• IPsec
  • OpenIKED — IKEv2 daemon which supports non-standard Curve25519
• ZRTP
  • ZRTPCPP — GNU ZRTP C++
• Other
  • TextSecure — encrypted messaging protocol derivative of OTR Messaging
  • Pond — forward secure, asynchronous messaging for the discerning
  • ZeroTier — Create flat virtual Ethernet networks of almost unlimited size
  • telehash — encrypted mesh protocol
  • bubblestorm — P2P group organization protocol
  • Apple AirPlay — stream content to HDTV/speakers

Networks

• Tor — The Onion Router anonymity network
• GNUnet — a framework for secure peer-to-peer networking that does not use any centralized or otherwise trusted services
• URC — an IRC style, private, security aware, open source project
• Serval — Mesh telecommunications
• cjdns — encrypted ipv6 mesh networking
  • Plus the Enigmabox — a Hardware cjdns router

Operating Systems

• OpenBSD — used in OpenSSH, OpenIKED, and in CVS over SSH
• Apple iOS — the operating system used in the iPhone, iPad, and iPod Touch
• Android — ships with Chrome, which uses Curve25519 in QUIC
• Cyanogenmod — version 11+ ships with TextSecure
• All operating systems that ship with OpenSSH 6.5+ from the OpenBSD Project

Software

• DNS
  • CurveDNS — a DNSCurve Forwarding Authoritative Name Server ^{also on github}
  • djbdns dnscurve patch — adds DNSCurve support to dnscache
  • dqcache — Recursive DNS/DNSCurve server ^{also on github!}
  • dq — a command-line tool to debug DNS/DNScurve
  • pymdscurve & dnspythoncurve — python authoritative server & recursive resolver
  • dnscrypt-proxy — securing communications between a client and a DNS resolver
  • dnscrypt-win-client — DNSCrypt for Windows (front-end to dnscrypt-proxy)
  • dnscrypt-win-client — DNSCrypt for Windows (front-end to dnscrypt-proxy)
  • dnscrypt-osxclient — Mac OSX application to control the DNSCrypt Proxy
  • dnscrypt-proxy-cydia — DNSCrypt for jailbroken iOS/Apple devices via Cydia
  • dnscrypt-wrapper — add dnscrypt support to any name resolver
  • Pcap_DNSProxy — A local DNS server base on WinPcap and LibPcap
• Web browsers
  • Google Chromium
  • Opera
• CurveCP related
  • CurveProtect — securing major protocols with CurveCP. Also supports DNSCurve.
  • qremote — an experimental drop-in replacement for qmail’s qmail-remote with CurveCP support
  • curvetun — a lightweight curve25519-based IP tunnel
  • spiral-swarm — easy local file transfer with curvecp [ author recommends another project ]
  • QuickTun — “probably the simplest VPN tunnel software ever”
  • jeremywohl-curvecp — “A Go CurveCP implementation I was sandboxing; non-functional.”
  • curvecp.go — Go implementation of the CurveCP protocol
  • curvecp — Automatically exported from code.google.com/p/curvecp
  • urcd — the most private, secure, open source, “Internet Relay Chat” style chat network
• MinimaLT related (all Pre-Alpha, not production ready, please contribute!)
  • The MinimaLT authors will soon release beta code. But some people are so excited about the protocol that they’ve written approximations based on published descriptions of it. Since I’m excited about MinimaLT as well, and since it shows serious public interest, I’m listing the following here.
  • mltpipepy — spiped style tunnel for the MinimaLT protocol implemented in Python 3
  • nimbus-network-minimalt — C implementation of MinimaLT
  • MinimaLT-experimental — an approximation of the MinimaLT protocol, in javascript
  • safeweb — Proposition of a faster and more secure Web (MinimaLT + DNSNMC)
  • Github lists something called “minimalt-go” by nimbus-network. It’s not MinimaLT! At a glance it uses the NSA/NIST curve P-256, and AES. Not X25519 and Salsa20 like MinimaLT.
• Tox Software
  • Tox — Free, secure, Skype alternative
  • toxcore — an easy to use, all-in-one communication platform
  • uTox — Lightweight Tox client
  • qTox — Powerful Tox client that follows the Tox design guidelines
  • Toxy — Metro-style tox client for Windows
  • CzeTox — School project: Tox client in Qt (alpha code)
  • OneTox — Tox client for the Universal Windows Platform
  • toxcore-vs — All necessary libs to build static toxcore using Visual Studio 2013
  • toxic — CLI Tox client
• SSH Software
  • OpenSSH — Secure Shell from the OpenBSD project
  • TinySSH — a small SSH server with state-of-the-art cryptography
  • Win32-OpenSSH — Win32 port of OpenSSH
  • asyncssh — an asynchronous SSH2 client and server atop asyncio
  • pssht — SSH server written in PHP
  • SmartFTP — an FTP, SSH, SFTP client
  • Dropbear — an SSH server and client
  • Tera Term — SSH client for Windows
• Other Software
  • Tor — The Onion Router
  • TextSecure — secure text messaging
  • OpenIKED — IKEv2 daemon for IPsec, from the OpenBSD project
  • WhatsApp — not all platforms implement X25519! To be safe, use TextSecure
  • Signal Desktop — Signal Private Messenger for the Desktop
  • Signal — Free, world-wide, private messaging and phone calls for iPhone
  • textsecure-go — TextSecure client package for Go
  • tweetnacl-tools — Tools for using TweetNaCl
  • haskell-tor — A Haskell implementation of the Tor protocol
  • Secrete — ECIES implementation with Curve25519
  • Tinfoil Chat NaCl — a high assurance encryption plugin for Pidgin IM
  • vcrypt — Toolkit for multi-factor, multi-role encryption
  • KinomaJS — A JavaScript runtime optimized for the applications that power IoT devices
  • srlog2 — Secure Remote Log Transmission System
  • encryptify — encryptify encrypts files
  • gobox — Trivial CLI wrapper around go.crypto/nacl/box
  • zkm — Zero Knowledge Messaging
  • qabel-core — Implementation of Qabel-Core in Java
  • Rubinius Language Platform — a modern language platform that supports a number of programming languages
  • servertail — quickly and easily see real time output of log files on your servers
  • cryptomirror — explores ways to make crypto user-friendly in non-crypto friendly environments
  • couch-box — Asymmetric encrypted CouchDB documents, powered by NaCl’s curve25519-xsalsa20-poly1305
  • saltcellar — libsodium based file encryption
  • SQRL — Secure Quick Reliable Login
  • curve-keygen — a utility to generate Curve25519 keypairs
  • confidential-publishing — Code for “A decentralized approach to publish confidential data”
  • cryptutils — Various crypto utilties based on a common NaCl/Ed25519 core
  • SMSSecure — fork of TextSecure which adds encrypted SMS support
  • gr-nacl — GNU Radio module for data encryption using NaCl library
  • up — sending a file from one computer to another using the nacl library
  • quicbench — HTTP/QUIC load test and benchmark tool
  • session25519 — Derive curve25519 key pair from email/password via scrypt
  • Bleep — Private instant messaging via secure, distributed technology
  • pcp — Pretty Curved Privacy
  • opake — Messaging with in-browser encryption using curve25519
  • CurvedSalsa — encrypt/decrypt files with Salsa20 & Curve25519
  • asignify — Yet another signify tool
  • nymphemeral — an ephemeral nymserver GUI client
  • hs-noise — encrypted networking in Haskell
  • CPGB — Curve Privacy Guard B, a secure replacement for GPG using ECC
  • SigmaVPN — simple, light-weight and modular VPN software for UNIX systems
  • fastd — Fast and Secure Tunneling Daemon
  • Simply Good Privacy — PGP-like system without web of trust
  • PoSH-Sodium — Powershell module to wrap libsodium-net methods
  • midgetpack — a multiplatform secure ELF packer
  • dhbitty — a small public key encryption program written in C
  • Threema — encrypted messaging app (closed source)
  • tappet — a tiny encrypted UDP tunnel using TweetNaCl
  • Osteria — secure point-to-point messenger
  • mcrypt — Message Crypto – Encrypt and sign individual messages
  • chdkripto — CHDK firmware – crypto modules (work in progress)
  • CurveLock — message and file encryption for Windows
  • Securecom Text — a messaging app for easy private communication with friends
  • srndv2 — some random news daemon (version 2)
  • GoVPN — simple high-performance secure VPN using DH-EKE
  • Core Secret — Secure secret sharing between Bluetooth Low Energy peers on iOS
  • AxolotlKit — a free implementation of the Axolotl protocol
  • pyaxo — A python implementation of the Axolotl ratchet protocol
  • reop — reasonable expectation of privacy
  • SUPERCOP — a cryptographic benchmarking suite

TLS Libraries

• BoringSSL
• Others coming soon, which is next?!

Libraries

• NaCl + wrappers & bindings
  • NaCl — Networking and Cryptography Library
  • μNaCl — The Networking and Cryptography library for microcontrollers
  • salt — Haskell bindings for NaCl
  • node-nacl — Node.js bindings for NaCl
  • node-djb-nacl — Node.js bindings for NaCl
  • PyNaCl — a python wrapper for NaCl
  • racl — Racket bindings for nacl.cr.yp.to
  • ruby-nacl — a Ruby wrapper for NaCl
• NaCl ports etc.
  • C: cNaCl — a CMake enabled fork of NaCl
  • C#: Chaos.NaCl — a cryptography library written in C#, based on NaCl
  • Javascript: ecma-nacl — JavaScript version of NaCl Cryptographic library
  • JavaScript: js-nacl
  • Python: slownacl — a pure Python implementation of the NaCl Python API
  • Rust: rust-crypto-nacl — Rust-Crypto-NaCl
• TweetNaCl + wrappers & bindings
  • TweetNaCl — a crypto library in 100 tweets
  • Erlang: TweetNaCl-Erlang — Erlang bindings for TweetNaCl
  • Jim TCL: jim-nacl — NaCl extension for Jim TCL (using TweetNaCl)
  • Objective-C: tweetnacl-objc — Objective-C bindings to the TweetNaCl crypto library
  • Python: Python-TweetNaCl — a wrapper around the C implementation of TweetNaCl
  • Python: python-tweetnacl — Python bindings to the “TweetNaCl” cryptography library
  • Python: libnacl — Python tweetnacl wrapper
  • Ruby: tweetnacl-ruby — TweetNaCl Ruby C-extension
  • Rust: rust-tweetnacl — Rust wrapper for TweetNaCl crypto library
  • Rust: knuckle — Rust bindings to TweetNaCl
• TweetNaCl ports etc.
  • Android: tweetnacl-android — TweetNaCl port to Android
  • C: tweetnacl-usable — TweetNaCl + randombytes()
  • Common Lisp: naclcl — A direct translation of TweetNaCl into Common Lisp
  • CouchDB: couchnacl — Use TweetNaCl.js from inside CouchDB
  • Go: go-tweetnacl — A Go port of the TweetNacl library
  • Java: tweetnacl-java — rewrite tweetnacl.c in pure Java
  • Java: tweetnacl-java — A Java port of TweetNaCl from the original C
  • JavaScript: TweetNaCl.js — Port of TweetNaCl / NaCl to JavaScript for modern browsers and Node.js. Public domain.
  • JavaScript: tweetnacl-nodewrap — Port of TweetNaCl / NaCl to javascript Node.js
• libsodium + wrappers & bindings
  • libsodium — a portable, cross-compilable, installable, packageable fork of NaCl (Frank Denis)
  • C++: sodiumpp
  • C++: Tears
  • Clojure: caesium
  • Clojure: naclj
  • Common LISP: cl-sodium
  • Common LISP: foreign-sodium
  • D: shaker
  • Delphi/FreePascal: libsodium-delphi
  • Elixir: Savory
  • Erlang: Erlang-NaCl
  • Erlang: Salt
  • Erlang: enacl
  • Fortran: Fortium
  • Go: GoSodium
  • Go: libsodium-go
  • Haskell: Saltine
  • Idris: sodium-idris
  • Java: kalium
  • Java JNI: kalium-jni
  • Java JNI: libstodium
  • Java JNI: sodium-jni
  • Julia: Sodium.jl
  • Lua: luasodium
  • Lua: lua-sodium
  • MRuby: mruby-libsodium
  • .NET: libsodium-net
  • NodeJS: node-sodium
  • NodeJS: Natrium
  • Objective-C: SodiumObjc
  • Objective-C: NAChloride
  • OCaml: ocaml-sodium
  • Perl: Crypt-Sodium
  • Perl: crypt-nacl-sodium
  • Pharo/Squeak: Crypto-Nacl
  • PHP: php-sodium
  • PHP: libsodium-php
  • PHP: halite
  • Pony: pony-sodium
  • Python: PyNaCl
  • Python: libnacl
  • Python: pysodium
  • Python: libnacl
  • R: sodium
  • Racket: part of CRESTaceans
  • Racket: natrium-crypt
  • Ruby: RbNaCl
  • Ruby: ffi-libsodium
  • Ruby: sodium
  • Ruby: jodid
  • Rust: Sodium Oxide
  • Rust: libsodium-sys
  • Swift: swift-sodium
  • Swift: NaOH
• libsodium.js — The sodium crypto library compiled to pure JavaScript using Emscripten
  • natrium-browser — libsodium.js wrapped with natrium api
  • haxe_libsodium — haxe bindings for libsodium.js
• Robosodium — Quick scripted compilation of Libsodium for Android
• Curve25519 standalone (native implementations)
  • ASM: DJB’s implementation (Dan Bernstein)
  • ASM: Sandy2x (Tung Chou)
  • ASM: curve25519-asm (Pieter Hintjens)
  • ASM: x25519-cortexm4 (Wouter de Groot)
  • ASM: curve25519-atmega (Michael Düll, Björn Haase, Gesine Hinterwälder, Michael Hutter, Christof Paar, Ana Helena Sánchez, and Peter Schwabe)
  • ASM: curve25519-msp430 (Gesine Hinterwälder)
  • ASM: curve25519-cortexm0 (Björn Haase and Ana Helena Sánchez)
  • C: curve25519-donna (Adam Langley)
  • C: curve25519-donna-floodyberry (Andrew Moon)
  • C: curve25519-mehdi (Mehdi Sotoodeh)
  • C: curve25519-meh (Marek Koza)
  • C (ATXMEGA): CurveX (Alexandru Mereacre)
  • C++ curve25519-uwp (Jeff R)
  • C#: curve25519 (Hans Wolff)
  • Cell Broadband Engine: celldh (Peter Schwabe, Neil Costigan)
  • Java: curve25519-java (Dmitry Skiba)
  • Java: curve25519-java (Trevor Bernard)
  • JavaScript: ed2curve-js (Dmitry Chestnykh)
  • JavaScript: curve255js (Michele Bini)
  • OCaml: Callipyge (OKLM WSH)
  • Perl: crypt-curve25519 (Alex J. G. Burzynski)
  • PHP: Curve25519 (Leigh)
  • PHP: PHP-Curve25519 (Leigh)
  • Python: python-pure25519 (Brian Warner)
  • Verilog: curve25519-verilog (Andres Erbsen)
  • VHDL: naclhw (Michael Hutter, Jürgen Schilling, Peter Schwabe, Wolfgang Wieser) — NaCl’s crypto_box
• Curve25519 standalone (wrappers & bindings)
  • Erlang: curve25519 (Lemoi)
  • Haskell: hs-curve25519 (Austin Seipp)
  • Haskell: curve25519 (Adam Wick)
  • JavaScript: curve25519.js (Robert Picard)
  • Node.js: node-curve25519 (Pedro Paixao)
  • Node.js: node-curve25519 (Jann Horn)
  • Node.js: node-curve25519 (Victor Gama)
  • Objective-C: 25519 (Frederic Jacobs)
  • PHP: php-curve25519-ext (Leigh)
  • PHP: curve25519-php (mgp25)
  • Python: pycurve25519 (Thomas)
• CurveCP
  • libcurvecpr — a low-level, networking-independent implementation of Daniel J. Bernstein’s CurveCP
  • libcurvecpr-glib — GLib bindings for libcurvecpr
  • libchloride — the networking layer for libsodium, based on CurveCP
  • libcurvecpr-asio — Boost.ASIO bindings for libcurvecpr (implementation of CurveCP)
• libzmq (for ZeroMQ) + alternative implementations
  • libzmq
  • C: libzmtp
  • Erlang: ezmq
  • Netty: netty-zmtp
  • Python: zmqproto
• Other Libraries
  • Go Crypto Library
  • Nettle — a low-level cryptographic library
    • Bindings available in Haskell, Perl, Pike, PostgreSQL, R6RS Scheme, and TCL
  • libaxolotl-android — Axolotl Library For Android
  • libaxolotl-uwp — An independent implementation of the axolotl protocol, loosely based on libaxolotl-java
  • PolarSSL — an open source and commercial SSL library
  • Botan — Crypto and TLS for C++11
  • libssh — multiplatform SSH library in C
  • Elligator-2 — C and Javascript implementations of the Elligator 2 algorithm for Curve25519
  • bc-java — Bouncy Castle Java Distribution
  • hs-nacl — Modern Haskell Cryptography
  • KCl — NaCl, but heavier (not compatable with NaCl)
  • Salt — NaCl cryptography library for PHP (not by the NaCl authors)
  • cryptonite — a haskell repository of cryptographic primitives
  • cryptofamily — a heap of primitives, algorithms, etc.
  • S/Channel — Secure channels over TCP/IP
  • cifra — A collection of cryptographic primitives targeted at embedded use
  • SodiumBox — LibSodium crypto_box_seal in Go
  • Personal-HomeKit-HAP — build HomeKit support accessories
  • haskell-crypto-box — An interface for authenticated public-key encryption a la NaCl
  • pony-zmq — Pure Pony implementation of the ZeroMQ messaging library
  • AeroGear — Libraries to simplify and unify mobile development across different platforms
  • sshj — ssh, scp and sftp for java
  • erlang-jose — JSON Object Signing and Encryption (JOSE) for Erlang and Elixir
  • HeavyThing — x86_64 assembler library
  • curve25519-java — Pure Java and JNI backed Curve25519 implementation
    • scrypto — Cryptographic primitives for Scala (includes Curve25519-Java wrapper)
  • dnscrypt-python — DNSCrypt Python Library
  • c25519 — Curve25519 and Ed25519 for low-memory systems
  • libaxolotl-java — Axolotl Library For Android
  • python-axolotl-curve25519 — curve25519 with ed25519 signatures, used by libaxolotl
  • python-axolotl — Python port of libaxolotl
  • python-axolotl-curve25519 — python wrapper for curve25519 library with ed25519 signatures
  • libaxolotl-php — Axolotl Library For PHP
  • libtextsecure-java — A Java library for communicating via TextSecure
  • libaxolotl-crypto-curve25519 — emscripten compiled version of curve25519 and ed25519
  • 0mq — An idiomatic Ruby wrapper for the ZeroMQ messaging library
  • SharpTox — Wrapper library for Tox core, av and dns functions
  • jnacl — Pure Java implementation of curve25519xsalsa20poly1305
  • libeddsa — cryptographic library for ed25519 and curve25519
  • tox4j — New and improved java wrapper for Tox
  • curve-protocol — Javascript implementation of the CurveCP protocol inspired by the ZeroMQ implementation
  • microstar-crypto — JavaScript cryptography library for Microstar, wrapping TweetNaCl
  • proteus — Axolotl Protocol Implementation
  • jodid25519 — Curve25519 and Ed25519 JavaScript
  • secret-handshake — Javascript-based authentication
  • helligator — haskell implementation of elligator
  • libelligator — A C++ Elligator2 implementation
  • pyelligator — Python binding for libelligator
  • shick_crypto — multi recipient NaCl-style encryption via libsodium
  • hs-curve25519-arithmetic — Arithmetic on Curve25519 in Haskell
  • nacl.js — JavaScript implementation of curve25519xsalsa20poly1305
  • potassium — Randomized forward-secure Curve25519-AES256-CTR-HMAC-SHA512 for Pythonista
  • Ordo — Symmetric Cryptography Library, which also includes Curve25519 support
  • riddler — cryptographic library for ed25519 and curve25519
  • seconn — A simple secure socket library for Go
  • elliptic — Fast elliptic-curve cryptography in plain javascript
  • librdns — Asynchronous DNS resolver with DNSCurve support

Miscellaneous

• Dan Bernstein: “An attacker who spends a billion dollars on special-purpose chips to attack Curve25519, using the best attacks available today, has about 1 chance in 1000000000000000000000000000 of breaking Curve25519 after a year of computation.”
• Dmitry Chestnykh: “You can write a program to generate Curve25519 private key faster than PGP generates its private key.”
• Adam Langley: “Of the concrete implementations of Diffie-Hellman, curve25519 is the fastest, common one. There are some faster primitives in eBACS, but the ones that are significantly faster are also significantly weaker.”
• Matthew Green: “Any potential ‘up my sleeve’ number should be looked at with derision and thoroughly examined (Schneier thinks that the suggested NIST ECC curves are probably compromised by NSA using ‘up my sleeve’ constants). This is why I think we all should embrace DJB’s curve25519.”
• Frederic Jacobs: “It’s incredible to realize that the TextSecure protocol enabled the largest end-to-end encrypted messaging deployement in history.”
• GnuPG: “For many people the NIST and also the Brainpool curves have an doubtful origin and thus the plan for GnuPG is to use Bernstein’s Curve 25519 as default. GnuPG 2.1.0 already comes with support for signing keys using the Ed25519 variant of this curve. This has not yet been standardized by the IETF (i.e. there is no RFC) but we won’t wait any longer and go ahead using the proposed format for this signing algorithm.”
• Ian Grigg: “In the past, things like TLS, PGP, IPSec and others encouraged you to slice and dice the various algorithms as a sort of alphabet soup mix. Disaster. What we got for that favour was code bloat, insecurity at the edges, continual arguments as to what is good & bad, focus on numbers & acronyms, distraction from user security, entire projects that rate your skills in cryptoscrabble, committeeitus, upgrade nightmares, pontification … Cryptoplumbing shouldn’t be like eating spagetti soup with a toothpick. There should be One Cipher Suite and that should do for everyone, everytime. There should be no way for users to stuff things up by tweaking a dial they read about in some slashdot tweakabit article while on the train to work… Picking curve25519xsalsa20poly1305 is good enough for that One True CipherSuite motive alone… It’s an innovation! Adopt it.”
• wolfSSL: “Curve25519 so far is destroying the key agreement and generation benchmarks of previous curves, putting up numbers for both key agreement and generation that are on average 86 percent faster than those of NIST curves.”
• Adam Langley: “Current ECDSA deployments involve an ECDSA key in an X.509 certificate and ephemeral, ECDHE keys being generated by the server as needed. These ephemeral keys are signed by the ECDSA key. A similar design would have an Ed25519 key in the X.509 certificate and curve25519 used for ECDHE. I don’t believe there’s anything needed to get that working save for switching out the algorithms.”

Timeline notes

• 2008-08-22: DNSCurve is announced by Dan Bernstein.
• 2009-06-02: Matthew Dempsky’s DNSCurve patch for dnscache is released.
• 2010-02-23: OpenDNS adopts DNSCurve.
• 2010-12-28: CurveDNS 0.87 is released.
• 2010-12-28: CurveCP is announced at 27C3.
• 2011-02-21: The most recent NaCl is released.
• 2011-02-21: Prototype CurveCP tools are included in NaCl.
• 2011-12-06: DNSCrypt is announced by OpenDNS.
• 2011-12-06: DNSCrypt for OSX initial public release.
• 2012-05-08: DNSCrypt for Windows is available.
• 2012-11-24: First release of dnscrypt-wrapper, by Yecheng Fu.
• 2013-03-09: Chromium enables Curve25519 key exchange code for QUIC.
• 2013-05-22: MinimaLT is introduced.
• 2013-06-05: Edward Snowden / NSA disclosures begin.
• 2013-07-19: First release of TweetNaCl
• 2013-09-15: Bruce Schneier recommends avoiding NSA/NIST curves. Curve25519 is safe.
• 2013-09-25: curve25519-sha256@libssh.org is proposed.
• 2013-10-13: TextSecure migrates to Curve25519.
• 2013-12-12: Tor adds Curve25519 support in version 0.2.4.19.
• 2013-12-24: GNUnet switches to Curve25519 in version 0.10.0.
• 2013-12-31: PolarSSL adds Curve25519 support in version 1.3.3.
• 2014-01-08: libssh adds curve25519-sha256@libssh.org in version 0.6.0.
• 2014-01-29: OpenSSH makes Curve25519 the default key exchange in version 6.5.
• 2014-02-16: First (experimental) release of TinySSH.
• 2014-02-17: Cloudflare announces plans to deploy QUIC.
• 2014-08-25: DJB recommends referring to Curve25519 Montgomery-X-coordinate Diffie-Hellman as X25519.
• 2014-09-30: wolfSSL seeks Curve25519 beta testers.
• 2014-10-26: dqcache is introduced by Jan Mojžíš.
• 2014-11-18: WhatsApp gains support for the TextSecure protocol.
• 2015-01-24: IETF CFRG adopts draft-agl-cfrgcurve-00, specifying Curve25519.
• 2015-03-04: “Curve25519 now supported at the wolfCrypt level, wolfSSL layer coming soon.”
• 2015-04-07: Nettle 3.1 adds support for Curve25519.
• 2015-06-12: Curve25519 now an IETF/TLS working group item.
• 2015-11-17: BoringSSL (from Google) adds X25519 support.
• 2016-01-20: BoringSSL: “Enable X25519 by default in TLS.”
• DNSCurve and CurveCP have always supported it.
• NaCl and libsodium have always supported it.

X25519 support coming soon!

• MinimaLT — A super fast, super secure transport protocol
• TLS — Transport Layer Security
• Ethos — An operating system to make it far easier to write applications that withstand attack
• wolfSSL — for use in TLS
• Microsoft TLS
• dnsdist — a highly DNS-, DoS- and abuse-aware loadbalancer (adding DNSCrypt support)
• curvecp-javascript — CurveCP protocol implementation in pure Javascript
• php71_crypto — Pluggable Cryptography Interface for PHP 7.1
• jc_curve25519 — Javacard implementation of Curve25519 (prototype, work-in-progress)
• ConnectBot — the first SSH client for Android
• sshlib — ConnectBot’s SSH library
• Cyberduck — Libre FTP, SFTP, WebDAV, S3, Azure & OpenStack Swift browser for Mac and Windows
• djbdnscurve6 — dnscache with DNSCurve & IPv6 support
• JackPair — secure your voice phone calls against wiretapping
• PuTTY — A Free Telnet/SSH Client
• cjdrs — cjdns implementation in Rust
• freepass — “TODO SQRL”
• molch — An implementation of the axolotl ratchet based on libsodium
• libsodium-laravel — Laravel integration for lib sodium
• mute — secure messaging (currently in alpha release)
• Tahoe-LAFS — Free and Open cloud storage system
• Cloudflare — “once QUIC makes the move from experimental to beta we’ll be sure to make it available for our customers.”
• gospdyquic — SPDY/QUIC support for Go
• Tox.NET — WIP reimplementation of Tox in C#
• opt-cryptobox — Optimized cryptobox self-contained library
• goquic — QUIC support for Go
• SC4 — Strong Crypto for Mere Mortals
• End-To-End — a Chrome extension that helps you encrypt, decrypt, digital sign, and verify signed messages within the browser using OpenPGP
• Yahoo End-To-End — Use OpenPGP encryption in Yahoo mail.
• TextSecure-Browser — TextSecure as a Chrome Extension
• curve_tun — TCP tunnels secured by Curve25519
• Dust — A Blocking-Resistant Internet Transport Protocol
• Twisted Python SSH — event-driven Python
• pouch-box — Asymmetric encrypted PouchDB, powered by NaCl’s curve25519-xsalsa20-poly1305
• Blight — a Tox client written in Racket that utilizes libtoxcore-racket
• GnuPG — end-to-end encrypted email. Note: Alternatives like reop support Curve25519 now.
• Noise — a secure transport protocol.
• BitTorrent Live — uses crypto_box from NaCl
• strongSwan — IPsec for Linux
• TextSecureKit — a boilerplate for Mac & iOS apps
• libopenssh — turn OpenSSH into a library

Source: https://ianix.com/pub/curve25519-deployment.html