Skkynet Opens OPC UA Lab in Yokohama

Hardware and software vendors and users now have a facility for testing OPC UA products.

Mississauga, Ontario, July 12, 2018 – Skkynet Cloud Systems, Inc. (“Skkynet” or “the Company”) (OTCQB: SKKY), a global leader in real-time cloud information systems, announces the opening of the Skkynet UA Lab in Yokohama, Japan.  Working in close cooperation with Skkynet partner BellChild and OPC development company Puerto Co., the Skkynet UA Lab will provide testing, development, and advisory services for users and vendors of OPC UA-enabled hardware and software.

“We are pleased to offer this center of excellence to the OPC UA community in Japan and worldwide,” said Paul Thomas, President of Skkynet.  “OPC UA is a robust and secure industrial protocol, and we expect to see a steady increase in implementations.”

The Skkynet UA Lab offers three kinds of support for its clients.  For developers who need to test OPC UA projects, the UA Lab provides powerful OPC UA servers with a large assortment of evaluation software.  For vendors who have a product on the market, the UA Lab offers an interoperability test environment, allowing each vendor’s product to connect with and test against all other vendors’ products.  In addition to these, the UA Lab has inaugurated its Worldwide OPC UA Network DEvelopment and Research (WONDER) program to test various ways of connecting OPC UA.  These include testing on untrusted networks using push technologies, utilzing proxy-enabled DMZs, tunnelling through firewalls, and incorporating the OPC UA Pub/Sub specification when those implementations become available.

“OPC UA is a sophisticated protocol, demanding much attention to detail,” said Minoru Yamazaki, advisor to Skkynet Japan and project organizer.  “Real-world experience is the ultimate evaluation criteria, and we are grateful for the support we have been receiving from a number of OPC UA product distributors, including MOXA, Contec, Comtrol, and Hi-Flying, as well as BellChild, and Puerto.”

Skkynet’s DataHub middleware, SkkyHub service, and ETK provide secure access to industrial data through OPC UA and other protocols, allowing users to fully integrate OT (operations technology) with IT systems and other applications anywhere in the world. Secure by design, it requires no VPN, no open firewall ports, no special programming, and no additional hardware. Secure integration of embedded devices, on-premise systems, and remote locations through seamless, end-to-end connectivity in real time lets users derive maximum value from Industrial IoT and Industrie 4.0.

About Skkynet

Skkynet Cloud Systems, Inc. (OTCQB: SKKY) is a global leader in real-time cloud information systems. The Skkynet Connected Systems platform includes the award-winning SkkyHub™ service, DataHub®, WebView™, and Embedded Toolkit (ETK) software. The platform enables real-time data connectivity for industrial, embedded, and financial systems, with no programming required. Skkynet’s platform is uniquely positioned for the “Internet of Things” and “Industry 4.0” because unlike the traditional approach for networked systems, SkkyHub is secure-by-design. For more information, see

Safe Harbor

This news release contains “forward-looking statements” as that term is defined in the United States Securities Act of 1933, as amended and the Securities Exchange Act of 1934, as amended. Statements in this press release that are not purely historical are forward-looking statements, including beliefs, plans, expectations or intentions regarding the future, and results of new business opportunities. Actual results could differ from those projected in any forward-looking statements due to numerous factors, such as the inherent uncertainties associated with new business opportunities and development stage companies. Skkynet assumes no obligation to update the forward-looking statements. Although Skkynet believes that any beliefs, plans, expectations and intentions contained in this press release are reasonable, there can be no assurance that they will prove to be accurate. Investors should refer to the risk factors disclosure outlined in Skkynet’s annual report on Form 10-K for the most recent fiscal year, quarterly reports on Form 10-Q and other periodic reports filed from time-to-time with the U.S. Securities and Exchange Commission.

Considering Prefab

An uncle of mine was an entrepreneur and quite a do-it-yourselfer.  His main businesses included a restaurant and a propane gas distributorship, but he was a real hands-on kind of guy, and spent a few summers building a cottage on Seneca Lake in Upstate New York.  It was an ongoing project, always in a state of “finishing.”

The first stage, a small one-story, was mostly done, with panelled living room and functional kitchen, although some of the bedrooms in the back were unfinished—partially drywalled with exposed plumbing and electrical.  The next stage was planned as a large two-car garage to be capped by a second story master bedroom and office with large glass doors and picture windows overlooking the lake.

That was the plan, anyway.  The reality was that his various businesses and other interests intervened.  For the several summers that my brother and I worked with and for him, the garage was his workshop, while progress on the second story proceeded in fits and starts.  A year or two after I’d moved away from the area, it was a heartbreak to find out that the cottage had caught fire and burned to the ground,  due to a short-circuit in the wiring.  Nothing useful was left but the original concrete slab.

I never got to see that cottage completed.  But my uncle was not deterred.  He rebuilt, prefab.  In a few weeks he had a very nice two-story cottage, with a two car garage and great views of the lake from picture windows on both stories.  Rather than wasting his time framing rooms, running wiring, joining pipes and hanging sheetrock, he was out on the water sailing, or cooking up a barbeque with his cousins and family.

The lesson for me?  Sure, maybe you can do it all yourself.  But should you?  It could take more time than you expect, and the results may not be what you were hoping for.  Sometimes it’s best to leave the tedious, difficult, and specialized work to the experts, and focus on what brings the most value, or the most fun.

As we explained in a recent article published in, this is the principle behind working with Skkynet’s ETK, and its OPC UA framework, rather than a software development kit (SDK).  Using an SDK can take an expert programmer 12 to 18 months to build an OPC UA server.  Meanwhile, a developer who uses the ETK gets a pre-built OPC UA server, and can focus on his or her applications.

Some people, like my uncle, seem to enjoy doing it themselves.  They rise to the challenge, and given enough time they can succeed.  And then there’s the prefab option: buy, install, and run.  The grunt work is done.  Drop your hammer and rig the sailboat.  That’s the benefit of the ETK’s OPC UA framework—the difficult and boring work is done, so the developer can focus on what he or she knows and does best.

Need to Speed Up OPC UA Development? Use a Framework

Developers who want to put OPC UA on an embedded device typically use an SDK (Sofware Development Kit) to speed up the project. Although an SDK can be helpful, using one to build an OPC UA server is still a big task, typically taking 12 to 18 months for an expert in OPC. Thankfully, there is another approach—use a framework. This article explains the three main advantages of using a framework:

  1. It resolves protocol blocking, a challenging obstacle to development .
  2. It can convert the OPC UA to the protocol the device may be using.
  3. You don’t need to learn OPC UA.

Using a framework (like the one provided by Skkynet’s ETK) allows a developer to bridge between the application logic and the OPC UA protocol and speed up development time.

The Kaspersky Report: It’s Not Really About OPC UA, a leading online publisher of automation-related content, recently ran a commentary on a new report from Kaspersky Labs about OPC UA. The Kaspersky report identified 17 critical security flaws in OPC UA software. But although the Kaspersky methodology may be sound, the commentary in suggested caution in drawing conclusions.

It turns out that the flaws noted by Kaspersky were simply because an OPC UA must listen for connections on a network, just like any other server on a TCP/IP network. The real problem is deeper, according to the commentary. Put simply, the standard approach to industrial data communications is not suitable for untrusted networks like the Internet. A better solution is not to allow any inbound connections at all.

Skkynet’s Approach Calms Recent Security Concerns

Eyebrows were raised among the industrial automation community last week when the well-known Kaspersky Labs issued a report titled OPC UA Security Analysis that lists 17 security issues in the OPC UA protocol and products. While we see no reason to doubt their methodology, we take a different approach to the question.

As we see it, the real issue is not the OPC UA protocol itself. OPC UA was created to allow client/server networking for industrial communication. The flaws that Kaspersky identified were visible on an OPC UA server that, by definition, is listening for network connections from OPC UA clients. Any application that listens for connections on a network can equally be a point of attack for a malicious hacker. This is not unique to OPC UA—it is a fact of the design of TCP/IP networks. Period.

Think about it. How did Kaspersky Labs discover the vulnerabilities in OPC UA and related products? Using a technique called “fuzzing”, they used a specially-constructed client application to send a rapid-fire barrage of messages at the UA server, each of which was slightly altered, or “mutated”, in some way from a standard message. Sooner or later one of these messages would crash the server or uncover an exploitable vulnerability. This technique can be used on any network-connected server, like a web server, VPN server, RDP server or vendor-supplied remote access server.

We would argue that Kaspersky Labs was searching for symptoms while overlooking the cause. What the report does not address, and indeed it is so obvious that it is easily overlooked, is that this kind of attack can only succeed if the intruder has access to the server in the first place. All software has bugs. Any program exposed to the Internet is fair game. However, as long as your servers are running on a trusted network and you keep all inbound firewall ports closed, you don’t run the risk of an attack from outside, no matter how persistent or devious the attacker may be.

The Real Problem

The real problem is that the standard approach to industrial data communications is not suitable for untrusted networks like the Internet. We are used to a client on the user side connecting into a server at the data source―after all that’s the classic server-client architecture. But for Industrial IoT this approach poses a serious risk because the client is often outside the trusted plant network. It needs an open firewall port into the plant to connect. This design itself is the fundamental reason for the security problem. Rather than expecting protocols or software to be bug-free and invulnerable to attack, it makes more sense to find a more secure design approach altogether.

A Better Approach

A better approach is not to allow any inbound connections at all. The whole Kaspersky Lab scenario was built on repeated client connections into the server network. What if the server (over which the attacker has no control) connects out to the client? If you can establish only outbound connections from a data source to a data user, then the entire threat vector is eliminated. With all inbound firewall ports closed, the plant network and all of its OPC UA servers become invisible. And you can’t attack something that you can’t see.

This is Skkynet’s approach. It is running in production systems worldwide, and it is fully compatible with OPC UA. By keeping OPC UA servers within the trusted network, and keeping all firewall ports closed, Skkynet’s approach enables secure Industrial IoT connectivity, while still reaping the benefits of OPC UA in the plant.

Note: A version of this article was recently published on the website.

What Drives Industry in 2017?

It’s big. It’s by far the biggest industrial automation show in Germany, in Europe, and possibly in the world. It’s SPS IPC Drives. “SPS” is German for PLC (Programmable Logic Controller), “IPC” stands for Industrial Process Control, and “Drives” are tools that control the speed of machinery. It comprises a dozen exhibition halls, each one practically a trade show in itself, filled with gigantic, colorful booths displaying robots, machines, and control system components. It’s where thousands of engineers, system integrators, machine builders and parts vendors gather for a massive show-and-tell featuring the latest and greatest—sensors, actuators, controllers, software, services and more.

The Cogent/Skkynet display was part of the OPC Foundation exhibit at the show, in the communications technologies hall. We had a demo of our completely integrated solution for Industrial IoT data communication and OPC UA (Unified Architecture), from embedded devices with ETK, to the factory floor with DataHub, to our SkkyHub service running in the cloud. We attracted plenty of interest, particularly for our ability to access data from inside a plant without opening any firewall ports, and using no VPNs.

Other exhibits featured IoT, and a few had working demos similar to ours, showing how they could put data from a sensor into the cloud. But there were significant differences. Most of them did not have bidirectional communication, and all of them had to make compromises on security and robust connectivity.

Data Communication must be Secure…

The two technologies most frequently mentioned for data communications were OPC UA and MQTT. Most users are finding out that OPC UA by itself cannot serve as an IIoT protocol, because like every industrial protocol, it functions on a client-server basis. An OPC UA client outside the plant needs an open firewall port at the plant to connect to an OPC UA server inside. This is inherently insecure, since any hacker could also enter the plant through that open firewall port. To surmount this obstacle, a number of companies have turned to the MQTT messaging protocol. Its publish/subscibe architecture allows it to make outbound connections. That does keep firewall ports closed, but MQTT is not suitable for IIoT for other reasons. Notably, it cannot guarantee data consistency.

… and Robust

Funnily enough, when you bring this up, people catch on quickly. I walked around the show and talked to people who had IIoT on their posters and brochures, who were demonstrating IIoT devices, and offering IIoT cloud services. Companies large and small, including some of the biggest names in the industry, are using or promoting MQTT or its close cousin, AMQP. And yet when I pointed out to them how MQTT is unable to guarantee consistent data, they soon understood. Everyone acknowledged that if an MQTT connection from a data source is broken, the data user will not know that his or her data may no longer be valid. “Isn’t that a problem? Couldn’t it be dangerous?” I would ask. “Yes,” they would admit, “but there isn’t any other way.”

Another Way

Finding out that there is another way opened a few eyes. People coming to our booth and those we met throughout the show were surprised and pleased to find out that there actually is a way to maintain a secure, robust connection for IIoT. There is no need to open any firewall ports or to use a VPN, and yet you can guarantee consistency of the data between the server and the client. All you need is the right technology, secure by design. Our task for the coming months is to continue sharing this message with the 1500+ exhibitors and 70,000+ visitors at SPS IPC Drives, along with anyone else who wants to connect industrial process control systems to the IoT.