About AI and professional focus

 While studying AI (both ML and AGI), I've made the following notes, which, possibly, will be of interest to others.

1. By "AI," we'll mark what is currently called "artificial intellect," but that's not intellect. This is just automation of solving certain tasks using specific machine decision-making algorithms - decision trees, neural networks, and some other mechanics. All those algorithms are based on data and require vast amounts of homogenous data for their operations and enhancements. It would be more appropriate to call this Data Science, yet the talk is not about science but about applications of this science. Hence AI. BUT this is not intellect as understood by humans.
2. Why is Python so popular in AI? The answer is quite unexpected. Python as a programming language for large products is not suitable. But its benefit is a fairly rapid mastery. BASIC of modernity of a kind. So, ML is not for programmers but for data scientists who may or may not be able to program. For them, Python is easier to master. The fact that everyone says "Python has more libraries" is not a problem because .NET also has ML.NET and wrappers for TensorFlow, Keras, etc. That is, if someone needs to implement ML in .NET - no problems. Is it possible to access Python from .NET? You can try using IronPython or approach the task via pythonnet. Thus, if you want libraries in Python, then there are solutions.
3. Various ML courses still teach primitive algorithms, "bricks." The nuance is that all these bricks have long been implemented in the above-mentioned libraries, and it is not algorithms that should be studied but when to use which algorithms. A modern data scientist will not write an own regression or some other primitive function - it's not just extra work (everything has already been written for us), but you are not able to use the implementation with ready-made bricks. It's like writing your SHA256 or AES128 - well, you wrote it, but then where to apply it, as all encryption libraries have and use their own implementations.
4. A consequence of (3) - a modern data scientist doesn't do programming at all but performs composition of blocks (low-code and no-code technologies) as well as builds and optimizes data pipelines. That's what is called MLOps now.
5. There exist two directions of operations and development of an AI specialist and AI business. The first one is the building of data pipelines, described in (4). That's a great job, well-paid and required by the market. But that is not programming. If you love "data" as an entity, then you'd like this job too. So, this work and this business are about data: the more data, the better. There are no genius ideas, disruptive technologies, sophisticated inventions, and similar breakthroughs. The foundations of ML are not rocket science: they have simple math and trivial data transformations. You will succeed in building a business here if you see data and know how to collect them and apply them to optimize certain business processes. To re-iterate, you need to possess huge amounts of data; only this gets you ahead of the competition. The second direction of action is the application of the ideas and capabilities of ML in solving vertical market tasks and problems. AI activities and AI businesses in this direction grow from narrow and specific scientific and technological needs. Here, you may have little data (or no data at all). But you may make a breakthrough when solving a scientific or technological problem. For this direction, you first of all need to be a specialist in some subject - chemistry, physics, biology (or you should have such a specialist), and then you'd search, which ideas and principles of ML and AI you can apply in this specialist's work. Everything between those two directions ("we can write code, and we want to apply this knowledge in AI" most often doesn't have practical applications and a business benefit. Consequently, the risks of such a business are not justified by the possible commercial results. 
6. Could one use ML and AI for solving tasks X, Y, Z? Most likely, no. Modern AI, based on large datasets and data streams, is hardly applicable when you have little or no data. For this, you need other technologies like AGI. Those are, unfortunately, put behind because they don't bring quick money to large players, capable of investing in those technologies. 

(this post has been originally published on my personal page). 

What really breaks SSL?

An article about how SSL is misused (or not used at all).

The point is that SSL itself is secure, and it's people whose mistakes and misunderstandings make SSL-protected resources vulnerable.

Why are companies bigger, than they are supposed to be?

When you look at the average IT company, you see the front-end (the product it offers) and that's all. Many people wonder why the amount of personnel is so large, for the seemingly simple product? Well, there are several main reasons, which I list below. 

1. Customer service and sales
2. Scalable Backend development
3. Research and optimization
4. Permanent security evaluation
5. Integration with others

1. Customer service and sales. This is the department (in IT companies it's often the same personnel for both tasks) that communicates with customers, prospects, and partners. It can be infinitely large, especially for a mass market product.

2. Scalable Backend development. Most (if not all) IT products (software) have a part, called back-end, which contains most of the business logic. For mass market products, this part must not just work properly, but also be scalable, i.e. be able to handle many requests concurrently. To do so, the backend runs on several computer systems simultaneously, and they must play nice with each other. such scheme of operations is called "distributed system". Design and maintenance of distributed systems are one of the most complicated tasks in IT industry, and there's always room for improvement in any distributed system.

3. Research and optimization. The efficiently designed and implemented system can perform much better, than humans, and human labor is nowadays much more expensive than computer systems. Thus it makes sense to put the most of the burden on computers. But their resources also have certain limits, and the more operations you can "fit" into a single system, the more commercially efficient and profitable (let's hope so :) your system is.

4. Permanent security evaluation. New ways to penetrate protection of computer systems are found and presented literally every day. This can lead to money loss or even more serious, even deadly threats. Obviously, this is not what any business would like to experience, so security evaluation, patching, further evaluation is the never-ending loop of work of IT security specialists.

5. Integration with others. IT systems rarely work in the isolated environment. Even when the software application works on the local computer, it is run on top of the operating system layer, and playing nice with the OS is a kind of integration as well. Now, the data must enter and leave the software system. Making this possible requires following certain standards, data exchange formats etc. All of this is also integration. Finally, the software rarely delivers the complete solution to some business problem. More often, the software is the part of the larger workflow and integrating into as many workflows as possible is important to deliver the better experience to customers and to grow the user base.

Some more manipulations with the cat's fur

As I wrote a number of times, PKI's reliance on Certificate Authorities, which could possibly work 30 years ago when it was originally invented, doesn't perform well now, when the number of CAs has grown significantly, and it has become possible for a wide range of shady entities, both governmental and private, to become CAs or to issue CA certificates and make them trusted on customer computers. This includes hardware vendors (remember Superfish issue), antivirus software (check Kaspersky's root certificate issues), corporate proxies and more.

There's a need to check in some way, that the certificates presented during the connection, are the ones that the original server intended to send. It turns out that there's no standard way to do this, and the browser vendors are not looking for efficient ways to address the problem either. There's a great article on Computerworld, which lists some of the possible solutions for the problem, with descriptions and references. It contains a couple of simple yet easy to implement approaches, which beg for putting them into RFCs and similar standards. Instead, Google goes for implementing hard-to-enforce and hard-to-use approaches like Certificate Transparency Initiative. My vote goes to Certificate Validation Framework. Also, you can choose your favorite approach :).

Ignorance as a key to malware

The very disturbing study, described in detail here, indicates that any security warning are not effective, cause in the worst case people simply not "trust" the warnings. I.e. they trust a fishing website more, than the respected developer of the web browser. Ok ...

I think that's the same reason people go for Trump in these elections.

The flipside of cross-signing

The Chinese certificate authority WoSign used shady practices when issuing the certificates. To make things worse, it acquired the Israeli company named StartSSL and supposedly made it use WoSign's infrastructure. And that infrastructure was either misconfigured, or intentionally abused - we can only guess now.

Now, Apple has removed the root certificate of WoSign from its Trusted Roots. However, the WoSign's CA certificate is counter-signed by two other CAs, and that gives trust to the WoSign's CA. Without explicitly blocking this CA certificate neither Apple nor any other software vendor can't effectively prevent the abuse of the PKI infrastructure, when co-signing is used.

I was a proponent of the approach that certificates must be signed by more than one CA. This makes the system harder to compromise. But counter-signature must be validated using logical AND, not logical OR. One must require all three trusts to remain valid, rather than rely on any of the signatures, like in the above case.

I am wondering, how many security breaches should happen until the industry starts moving in the direction of requiring more than one valid signature on each certificate (or at least on CA certificates).

And I am afraid, that unless such movement is implemented in standards, we'll see vendors going in all directions implementing incompatible, if not mutually exclusive, approaches to strengthening PKI.

Full story here.

The inhuman factor

It would be an anecdote if it didn't reflect the poor situation with humans dragging severely behind  the development of technology.

The website of Social Security Service of the US attempted to introduce two-factor authentication. The idea was cancelled after it appeared, that only about 35% of the target audience know, how to read SMS on their phones.

Well, the target audience is those after 65 y.o, so no wonder. But these same people, who can't manage reading a couple of digits from the screen, and typing them back, are still allowed to vote and define the future of the younger generations.

Actually, we'd call all those people technically illiterate. They've learned to read and write, but didn't learn to understand technology.

For those people only biometric authentication such as FIDO UAF could probably work. And that's another investment, which most retired people can't afford. A Catch 22 of a kind ...

A password as a lever

A nice story about how passwords changed the life of the author.

And you know what? It's a great idea. Just try it. 

How open-source kills innovation

The terrifying stories about notebooks with thousands of confidential data records being lost come every other week. The best solution for this problem (apart of not carrying the notebook or the data) was to encrypt the data at rest. And this is to be done using either whole-disk encryption (not always feasible or even supported), or by creating virtual encrypted disks.

The niche of virtual encrypted disk software was initially occupied by PGPDisk (first by PGP Corporation, now by Symantec, that purchased PGP Corporation). Later the open-source alternative, TrueCrypt has appeared. There were several commercial attempts made to compete with TrueCrypt, but those alternatives didn't get popular because why pay when you can get it for free.

Ok ... And now the X day has come and TrueCrypt was declared to be insecure, and it was abandoned by the developers as well. Not a problem for open-source, you might say, as one can make a fork, plug the security holes and release an update. Yes, to some extent. Besides the lack of one important factor - motivation. Maintaining somebody else's software is not a big fun, especially when it's a badly designed kernel-mode driver (which is the core of TrueCrypt). And when it's done for free, there's always something more important in the to-do list, as you can imagine.

There were several groups that attempted to fork TrueCrypt (CipherShed and VeraCrypt are just two names). But they have kind of failed.  Neither CipherShed nor VeraCrypt have a good track of frequent releases and bug fix updates. Bugs remain numerous, support is not provided (see "motivation"). We call that DoA.

Now, we (the company I've been working in for all my life) have the products (kernel-mode drivers, encryption modules) that would let us create such software relatively easily. But we never did this, exactly for the reason of necessity to compete with open-source. TrueCrypt has effectively blocked the market for us. And we are not alone. I know at least several other attempts to build solutions for data encryption on disk level (say "virtual encrypted disks"), and none of them are successful for the same reason.

Ok, but do we have a chance once TrueCrypt is gone? Well, no. Truecrypt is dead but not gone, neither are VeraCrypt. While that buggy open-source is still available, people will prefer living with bugs to licensing the maintained product for a fee. And this is true for both personal and business users (the latter ones are also driven by people, who are used to asking the initial question of why pay for what seems to be free).

Well, I would happily say "good luck" to the world of socialism and open-source, if we could have at least some solution of the problem (how to create the encrypted disk).

Suggestions, anyone?

One more try to skin a cat

I mentioned several times before, that the proper and relatively simple way to bring back trust in PKI would be to replace the existing tree-like hierarchy of X.509 certificates with something, which should ensure, that no CA (Certificate Authority) breach alone would compromise thousands of certificates and millions of TLS connections and signed documents.

Obviously, counter-signing all CA certificates in another one or two certificate authorities would be a logical step. And this is exactly what Microsoft has been doing with code-signing certificates for kernel-mode signing for years.

There's a different approach available as well, though. This is splitting of the private key (of CA certificates, as I understand) among several CAs. This approach is offered by Apache Milagro project.

At first sight the project seems to offer great ideas and great solutions. Well, until you start looking at practical applicability and openness of the project and of the formats and protocols besides it. The makers didn't go for standard RFC-defined protocols. Neither they opened their protocols or made them a standard.

In opposite, the project is offering a library for some programming languages and platforms. This is the approach that corrodes the industry. As often said, open-source != free. The open-source project doesn't mean an open standard for the community to implement. In opposite, we are seeing that the vendor is trying to push his proprietary solutions to the market by declaring them as open-source.

I strongly believe, that the developer community should not use such solution, as it is more of a troyan horse, than an open standard that improves the existing corpus of  industry-adopted PKI-related standards.

A magic bull.t

As a provider of solutions, related to security and data protection, we are often asked for some magic software, which will let the software developers and their customers protect the data from copying.
Moreover, such software should work on a platform, which was designed to be open, modular and to large extent hackable (and no, it's not Linux).

The problem with such requirements is that they contradict and conflict each other. The open platform means the ease to get into other processes' memory space (not that this is trivial, but very much possible) and copy bits and bytes from it. Protection means prevention of such operations.

Then, copying of information is the cornerstone of computer engineering and information-related sciences. Any use of information that you can imagine exposes this information to the outside world. And once exposed, this information can be translated further, and thus copied. This means that information is unusable without freedom to copy it. The question of whether information exists at all, if it can not be observed, should be left to philosophers, and we are more interested in practical aspects of this feature of information.

Copying of information is possible at any stage of its lifecycle, from the moment it is placed in the medium beyond your control, and up to the moment when the information disappears in the black holes billions of years later.

Talking about practical matters, such as copying of the document that you give to someone, you can not prevent copying of information. You can only make this information unusable (by encoding it in some way) and take measures to restrict the user from decoding this information in an uncontrolled manner.

What does this mean when applying the above said to documents and data that you distribute? Unfortunately, not very bright future for the classified secrets of your company. Once the document is decoded, it is used in one way or another. It is shown on display or printed by the legitimate user. It can also be captured by the hacker, trojan application or a spy sitting with a powerful electromagnetic antenna in the opposite building and listening for emissions of the computer display. Displayed or printed information can be copied, that's obvious. The information decoded in memory can be copied in decoded form to some other media. And the data of the document opened in the office suite can be easily transferred to another application via the system clipboard.

The described copying is easy to do on general-purpose systems like Windows. Would the closed system protect your information from being misused and abused? In theory, it could. Practically, though, prevention of leakage of information in serious organizations takes much more than a closed system, and usually involves restricted access to the rooms, no windows in such rooms, proactive protection measures like scanning of the electric networks, air conditioning systems, etc. for spying electronic devices and more. It's doubtful that you could enforce your recipients of data to take such measures.

So what is it all about? Is there no solution? If you search for "DRM" or "digital rights management" in the search engine, you'll get millions of links and dozens of software solutions. Yet, they (at least most of them) don't  claim absolute protection, but they promise to make stealing of information much harder. This is doable, and the question is how hard-to-crack is this or that protection.

We (our company) don't offer DRM solutions. We sell [licenses for] components, which can be used in building such solutions, and those components do make copying of information harder. But we also realize the shortcomings of most general approaches. If you let your file be opened in MS Office, then the user can copy the data to the clipboard or just save the file elsewhere. And neither our components nor the DRM solution itself can effectively counteract this without severely restricting users' capabilities to work with the data.

To make your life harder, let me remind you, that information carved in stone can also be copied using the simple tool called "camera". So if the information is so valuable that the risk of copying it can not be tolerated - don't disclose this information. Or take other, non-technical measures to secure your information and your position. NDAs, license agreements and alike could be a better defense than the most sophisticated DRM software.

Why Cloud security is impossible

Yesterday I've come across a rather old, but still actual (and even more and more actual, I'd say) article, that explains, why in-browser cryptography isn't going to work.

The article is "What's wrong with in-browser cryptography". It is written from security researcher's point of view, and as such is focused on flaws of the in-browser cryptography model. However, out-of-browser (but initiated by the server-side code) model is flawed equally (if not more) seriously, as an in-browser one. It doesn't matter, where the cryptography code is located - will it be some JavaScript in the web page, or a browser plugin or WebCrypto API offered by the browser itself. As long as the web page is changed dynamically, the user can not be sure, that the information is really encrypted, and that it is sent to the intended recipient. SSL/TLS does NOT ensure such security, unlike what most users think.

The article makes a good point, that with desktop software you can always capture the code that was executed and analyze it, in order to find what is being done and where the data is sent. And the code is signed, proving (to some extent) that it is authentic and has not been altered. With web pages such analysis and protection are not possible, because they can be easily altered by the server or by third-party actors (like browser plugins etc).

Browser applets like Flash and Java could solve the problem by applying code signing of applets. Unfortunately, in their desire for openness (which in most situations contradicts to security) the industry has rejected "closed" solutions that applets offer in favor to everchanging HTML, which makes security of user's data a distant dream.

One of solutions would be development of signed scripts, which could be signed with certificates as much as applets are. Unfortunately I didn't see any widespread attempts to introduce "secure Javascript" or "secure web pages". If you came across some, please let me know.

PKI reforms starts. Kind of.

Microsoft has lost faith in more than 20 CAs.

Still this is a partial measure. The chain is as strong as its weakest link is. If we have a web server certificate, signed by CA X , whose CA certificate is issued / signed by (trusted) root CA R, the X can be the weakest link, and no Microsoft measures will help prevent this link to be broken. This is exactly what happened in previous cases, when sub-CAs (like those X) issued certificates in violation to PKI rules and practices.

The solution? Web of trust. This would require certain modifications of the PKI, but the requirement for the end-entity certificate to be signed by at least two CAs would eliminate most issues related to wrongdoing by sub-CAs. Look - if you are an attacker and you hijack CA X , there's little use in this - you would need to hijack CA Y and/or CA Z . This is possible, but much more complicated and imposes higher risks to your attack to you.

In general there's much there that can be borrowed from OpenPGP. CA (Issuer) can still be present in the certificate, but there can be other extensions like subsignatures or counter-certificates included, and that would significantly increase the protection level.

A "fatal flaw" which is neither a fatal, nor a flaw.

The article in SC Magazine talks about "security flaws" in Kerberos protocol.  But what are those flaws about?

If we dig deeper, the only phrase in the article suggests that "if the attacker knows user's secret key, he can replay authentication without the need for user's password". Actually this is not a flaw. If the attacker got to user's secret key somehow, the user and the network are already in trouble, because this means that the attacker has already found some flaws elsewhere.

Now, Kerberos' shortcomings and disadvantages were known for years, and the discussed one was known as well. This is why Kerberos is not recommended and is replaced by modern protocols like SAML and OAuth even in intranets.

To sum it up, digging the grave and finding old flaws and bringing them back to the sunlight is an easy way to establish yourself as a security researcher, but you still need to look at the roots. And protection of credentials and use of multifactor authentication are the things that separate good security from the bad one.

HTTPs as it could be

Google has reinvented the wheel HTTP and called it HTTP/2. This comprehensive article about HTTP/2 describes how the web will benefit from this new protocol.

The problem with HTTP/2, as with most of what Google does is that it was designed by coders, not by system architects. The protocol severely lacks internal clarity and integrity. The server should behave in many (at least 4) completely different ways depending on what it supports and what the client requests. It's like trying to combine the truck's wheel with the bike one.

The authors are definitely not readers but writers. There exists SSH family of protocols, which does a thing very similar to what HTTP/2 does. And SSH has quite complicated but logical internal structure. The only thing missing from SSH (not exactly missing but not used) is X.509 certificates and/or OpenPGP keys - while both are in theory supported as authentication methods, almost no real software supports these methods (our SecureBlackbox supports OpenPGP and import of keys from X.509 certificates). Meanwhile HTTP/2 is a combination of old HTTP, new protocol (completely unrelated to HTTP) with fallback to HTTP, and more. Probably the authors of HTTP/2 are adepts of the pastafarian church.

The authors could easily learn how to design the multiplexing scheme right, but, as said, they are likely not readers.

Hitting him with nails

PKI is having hard time, as more and more human mistakes are revealed, which undermine PKI's position.

In fact,  PKI is not about technology, its about people actions. People forget or don't care to guard their property (private keys, in this case). This is common - people are negligent. There was a study several years ago, which revealed that a huge part (40-something %, if memory serves) of office workers shared their passwords for a chocolate bar. Why would they invest time and resources into guarding other one's secrets, if they don't guard their own?

Another nail in the coffin

of PKI as we know it. Dell has introduced a huge security hole in its devices.

And more complete coverage, together with remedies, can be found here.

Invest in your own security first

Iboss Cybersecurity raised $35 million from Goldman Sachs' Private Capital Investing group, the article tells us.

At the same time Goldman Sachs has deployed an SSH/SFTP server for their corporate operations, and has built it on the outdated version of the open-source SSH server library. Moreover, they've implemented the server badly, in the way that is incompatible with the wast majority of SSH client implementations. They have probably saved a couple of thousands by choosing an in-house (or, maybe, even worse, outsourced to overseas junior developer assistants) implementation based on outdated open-source, instead of paying for the supported commercial solution without such nasty bugs. At the same time they have found 35 mln. to invest into third-party something. Good job, security boys. 

On hitting nails with a microscope

The newly presented RFC introduces probably the most contradictory extension, and by itself is the one of the most meaningless RFCs adopted in the last 20 years.

The address of the RFC is https://www.rfc-editor.org/rfc/rfc7685.txt and it defines the padding extension, whose only function is to insert some zero bytes into the ClientHello packet of the TLS protocol. What's the purpose, you might ask? The purpose is to work around the bugs in some implementation(s) that is/are confused by certain lengths of ClientHellow packet.

You've got it right. Instead of fixing bugs (or pushing the developers to fix bugs) they invent extensions to make other developers complicate their software with those extensions to work around the bugs.

Tolerance is acceptable to people of different race/origin/group. Tolerance to bugs in unacceptable. Tolerance to idiocy is not acceptable either.

On reinventing the wheel

Google did it again, and there's a kind of hype around this new wheel.

Protocol Buffers are a bit simplified form of ASN.1 notation, which has been in use for decades. They even mention BER (Basic Encoding Rules, a form of ASN.1) but hide the "ASN" name.

This is what happens when imported eastern developers are writers and not readers.

Sometimes I feel pity that standards and protocols are not patented. One should prosecute those "reinventors" for plagiarism (taking the industry-adopted standard, hiding its name and claiming it the new protocol or something).