ioanpopovici

The sharp tool

Cloud is long gone my friends, long gone. Cloud computing is now just a tool for a ubiquitous computing society.

Allow me to clarify: simply, there’s absolutely no aspect of our contemporary society that is possible without constant, continuous, invasive and maybe pervasive involvement of computing. The so-called “pervasive computing” (Eva Nieuwdorp). I’m not going to discuss anything about the so-called pervasive dimension of ubiquitous computing, but I am going to leave the concept printed here. It fits well with one of the points I am going to make here.

Ubiquitous computing is the reality – so, not only the concept – where computing appears anytime and everywhere, anywhere. Let’s let this sink in for a moment.

There are many technical moving factors that make ubiquitous computing possible, for example:

Hardware miniaturization
Hardware affordability
Software affordability
UI and UX leaps
Communication infrastructure affordability
(so many more)

If we are to go into psychological moving factors, we would totally open-up a whole different world, so, we are not going to do that.

The reality is that we find ourselves in a compute-omnipresent society for a long time. There is nothing really new about all of this.

The TNT that actually placed the true ubiquitous in ubiquitous computing was the dawn of cloud computing. The ability to have computing as a service, any computing. The ability to “order random computing”. The ability to to LEGO with computing units on a global playground. Once this ability was available to the masses everything changed. Actually, the plain analogy with LEGO is not 100% right. It is like you always had the LEGO pieces, and now, by some magic, you can order magic part, place it inside your LEGO structure and it suddenly turns to reality. Magic and dangerous at the same time. Like black magic dust.

At the beginning…

There was, and maybe there still is, a lot of hype around cloud computing. You know, being able to rent and integrate the best of the best of a finished product in terms of computing is always going to be hyped-up.

At the beginning there were a lot of arguments about the “as-a-service” versus “ownership and independence” of computing “stuff”.

At the beginning there were a lot of arguments around the reliability of “the cloud”

At the beginning there were a lot of arguments around the security of it all.

At the beginning there were a lot of arguments about the cloudonomics of it all. Economies of scale, they said.

And now…

Now, the ownership problem was resolved. “People” asked, and the “people” have obtained the possibility of getting everything in and out of the “public cyberspace” as they please. We can run today an app in the cloud, and tomorrow in your datacenter, together with data, traffic, whatever.

Now, the reliability got to, I think, almost the best you can have. Proven in war.

Now, the security can no longer take place outside the cloud.

The twist

The last standing post is the cloudonomics. The turn here is that businesses moving to the cloud understood that the cost factor has to be balanced by the possibilities that you now have, post adoption. Optimizing the cost has to be balanced with getting more value for your buck.

If your business doesen’t find a way to benefit out of the fact that it can now be globally available, you have failed a bit

If your business doesen’t find a way to benefit out of the fact that it can now fairly easy make use of outstanding technology (AI/ML, BI, data archiving, data handling, etc) you have failed a bit more

If your business doesen’t find a way to benefit out of the fact that it can now stay available / grow in an elastic manner, you have failed a bit more.

We could go on forever.

It is about how “your business in the cloud” should incorporate computing in general, and contribute with some weight in developing the ubiquitous computing. That’s the sweet spot. Your cloud adoption is 100% successful when you get more ubiquitous.

The sharp tool

Cloud computing is to ubiquitous computing what a hammer is to a nail. This is not a hardware vs. software analogy, this is not a hardware vs. hardware analogy, this is not an infrastructure vs. service analogy. It is just a tool analogy.

If you know you are going to be hit by a hammer, you’d better be sharp at the other end.

P.S. building sharp tools is going to be the subject of the next topics.

Cheers.

Ranting about surveillance

In Romania, there’s a lot of law being in either in debate, or passing passed about giving the authorities direct abilities to get all e-data. E-mails, IMs, mandating the vendors to hand unencrypted data out. Please read this again.

Now, I want to lightly share some of my experience in working for some top cybersecurity ‘consulting’ companies. (lightly, because of NDAs)

Now, the layout is as follows: justice, law enforcement, and ultimately governments are mandating surveillance when justified. Alright Good.
The surveillance is happening anyway (phone taps, physical tracking, e-mails, IMs, and whatnot) with help from various agencies that are specialized in doing that.
The level of expertise that various govt. agencies have in terms of electronic surveillance is not always up-to-date. This is to say that their capabilities are limited. This is normal. When they face a situation where they can’t pursue a surveillance task, they outsource. There are cybersecurity companies that offer such services. These companies have cybersecurity researchers that are on top with various 0Days and the corresponding exploits and they master this.

How do I know this? I was one of these guys that offered cybersecurity research services for such a company. Repeatedly. Actually only two times, for two different companies. So not a lot of experience here. Just enough. I’m not going back there!

So, what’s my problem?

Let me guide you through an example:

Assume there’s a mandate that asks for IMs sent by the suspect. This is currently achieved, usually, by compromising the user’s device (phone, laptop, PC, MAC, whathef**kever) with some malware that is usually designed by one of these contracted companies. Surveillance happnes ON THE COMPROMISED DEVICE ITSELF.

Surveillance does not happen on the ‘encrypted wire’, or on the IM vendor’s infrastructure, but on the TARGETED DEVICE.

Now, suppose this new law passes, that will mandate the IM service providers to hold unencrypted data (or hold encryption keys) FOR EVERYBODY, ‘just in case’ a mandate is thrown away.

Do you see the problem yet ?

Jesus Christ, we live in a f***ed up world !!!

Mid-workshop surprise!

Something weird and nice happened to me today.

Several times a year, I accept requests for guiding cybersecurity workshops for various clients. Usually they fall into the category of web application security, or software development security. Not more than several (max 5) times a year because this will greatly impact my performance in other areas.

So one client requested a web applications security workshop that must be focused on OWASP guidelines. It is awesome for me. I always like OWASPs content. Sometimes, I even have the privilege of contributing to it. When I provide this service, I never prepare exhaustive slides for presenting an already well established material, such as the one from OWASP. I just go on the website and work with that as a prequel to my deep examples.

So what happened? Mid-workshop, the OWASP Top 10 W.A.S.R. changed. Bam! “Surprise M**********R!” Deal with that!

Now, during these events, I usually bring a lot of my experience in addition to whatever support material we are using. Actually, this is why someone would require guidance in going through a well-established and very well built security material, such as the one from OWASP.
When I talk and debate, and learn together with an audience about cybersecurity topics, I always emphasize things that I consider to be insufficiently emphasized by the supporting material. I say emphasized and not detailed, and please be careful to consider this difference.

Insufficiently emphasized topics

Traditionally, OWASP’s guidelines and material did not emphasized enough, in my humble opinion:

The importance of using correct cryptographic controls in the areas of: authentication and session management, sensitive data exposure, insufficient authorization
Insecure design in the areas of: bad security configuration, injection problems, insecure deserialization
Data integrity problems. Loop to #1.

I usually spend spend around 10-11 hours from 16[or more] hours workshop on the three topics above. Very important stuff, and, traditionally overlooked in most teams that I interact with.

What changed?

It was a nice surprise to see that in the new TOP 10 W.A.S.R. OWASP included my three pillars and emphasized concepts the same way I like to do it. They even renamed sections according to my preference. Like the second position (A2) is now called Cryptographic Failures. AWESOME!
They explain stuff in a more holistic manner, as opposed to just enumerating isolated vulnerabilities. AWESOME!
Finally. It was an extremely good argument for the team that I was leading, about the way I spent my time on the three topics. I felt good about them 🙂
Alraaaaight, I felt good about myself too!

Oh, and P.S: For the first time in.. what now, more than a decade (?!) OWASPs Top 10 W.A.S.R. does not have the top position occupied by injection problems. Either the web has grown exponentially again, or we have escaped a boundary. The boundary of absolute stupidity 🙂

Cheers!

Breaking through passports

A fairly long time ago, at blackhat (as far as I remember) somebody came on stage with an implementation of some proposed design of an electronic passport and proved its extremely worrying security flaws. I’ll leave the pleasure of researching the event to you.
Back then (maybe around 2001-2003?), the spirit of “blackhat” (or whatever event it was) was free, and if you were following that kind of security events you were consistently exposed to serious security researchers challenging the disastrous security implementations of either mainstream technology providers (such as Microsoft 😉 ) or of the govt digitalization.

What does this have to do with passports today? Well, they are a bit more secured thanks to that kind of involvement. Secured for both their users as well as for their governments.
Well, even if they were not so secured, the biggest looser of a flawed normal passport is its government. The projected user impact is fairly low. Identity theft by means of passport forgery or “torgery” is not a huge phenomenon.

Legitimate concerns for any passport users

From the user security perspective, let’s explore:

Who does the passport say that I am ?
How do I know I carry a valid (authentic and integral) passport at any time?
What does the document scanning say about me ?
- e.g. it was scanned while passing through customs, ergo anybody that is able to see a record of that scan will know that I was there at a specific point in time

Extrapolating to COVID passes

Well. As far as the ethical concerns, I’ll leave those up to each and every one of you.

But as far as the security goes, I have a few very worrying concerns:

The implementation details are not ~~widely~~ available.
There are alot of security incidents with these documents. And they are not and cannot be hidden even in the mainstream media. (https://www.dw.com/en/security-flaws-uncovered-in-eu-vaccination-passport/a-58129016)
How do I as an owner and user of the pass know WHO and when views or verifies my scans.

I am not going to continue the list, it is already embarrassing

This last one is a bit concerning.
Here’s why: with a normal passport, once scanned, the person that gains or has access to a list of these scans knows that you went over some border sometime.
However, with COVID passes the same actor that has or gains access to your passport scans, knows where you are kind of right now. Remember, you’ll scan your pass even if you go to a restaurant.

What do I want?

As a COVID pass user I want to have the certainty that no passport scans are stored anywhere. And I do not want anybody except the scanner to be able to see my identity. Because the moment they do, they’ll know where I am and what I’m doing. And this is unacceptable. Mainly because the scanning frequency of such a pass can be daily for some of us.

So, can I get what I want ?

I have tried to get implementation details Both directly, by asking it, legally, and through the security community (both academic and professional). The result ? No result. The public debate(s) prior to implementing and adopting these passes were a complete joke.
How long until XXXX gets a hold of a list of my scans and then follows me around, or worse. Seems far fetched ? Take a look at the latest data leaks 😉

But as the philosophers Jagger and Richards once said: “You can’t always get what you want!”

( https://www.youtube.com/watch?v=Ef9QnZVpVd8&ab_channel=ABKCOVEVO )

Some concerning technical and ethical reviews

A lot, has been going on lately. So much so, that I do not even know how to start reviewing it.

I’ll just go ahead and speak about some technical projects and topics that I’ve been briefly involved in and that are giving me a fair amount of concern.

Issue number x: Citizen-facing services of nation states

A while back, I made a “prediction”: the digitalization of citizen facing services will be more present, especially as the pandemic situation is panning out. (here) and (here). I was right.
Well, to be completely honest, it was not really a prediction as I had two side (as a freelancer) projects that were involving exactly this. So I kind of had a small and limited view from inside.

Those projects ended, successfully delivered, and then came the opportunity for more. I kindly declined. Partly because I’m trying to raise a child with my wife, and there’s only so much time in the universe, and partly because I have deep ethical issues with what is happening.

I am not allowed to even mention anything remotely linked with the projects I’ve been involved in, but I will give you a parallel and thus unrelated example, hoping you connect the dots. Unrelated in terms of: I was not even remotely involved in the implementation of the example I’m bringing forward.

The example is: The Romanian STS (Service for Special Telecommunications) introduced the blockchain technology in the process of centralizing and counting citizen votes, in national or regional elections that are happening in Romania. You can read more about it here, and connect the dots for yourselves. You’ll also need to know a fair amount about the Romanian election law, but you’re smart people.

The Issue?

Flinging the blockchain concept to the people so that the people misunderstand it. Creating a more secure image that necessary. Creating a security illusion. Creating the illusion of decentralized control, while implementing the EXACT opposite. I’m not saying this is intentional, oh, no, it is just opportunistic: it happened because of the fast adoption.
Why? Blockchain is supposed to bring decentralization, and what it completely does in the STS implementation is the EXACT opposite: consolidate centralization.

While I have no link with what happened in Romania, I know for a fact that similar things shave happened elsewhere. This is bad.

I do not think that this is happening with any intention. I simply think there is A HUGE AMOUNT of opportunistic implementations going on SIMPLY because of the political pressure to satisfy the PR needs, and maybe, just maybe, give people the opportunity to simplify their lives. But the implementations are opportunistic, and from a security perspective, this is unacceptable!

Ethically

I think that while we, as a society, tend to focus on the ethics in using AI and whatnot, we are completely forgetting about ethics in terms of increased dependency of IT&C in general. I strongly believe that we have missed a link here. In the security landscape, this is going to cost us. Bigtime.

Blockchaining the energy

Several weeks ago I have finished migrating one of the past projects I have been involved in to the blockchain technology. Back in the day that I was leading that project, blockchain was not the default choice. So, “the guys” called and wanted me to come back and offer some insights while migrating everything to blockchain. Piece of cake. Plus, blockchain was a perfect fit for the job. A real pleasure, and not too much work to do. Easy money, how they call it.

However, this got me thinking. I have a weird passion lately in the area of decentralized energy grids, smart energy grids and grids in general. It was spiked by one of my friends. I haven’t had the chance to work on a serious energy project until now, but this didn’t stop me from fantasizing

What do I fantasize about?

The potential use cases of blockchain within the energy sector. So, here it is:

Auditing and regulatory needs in terms of transparency. Obviously, here the native immutable records of a DL with the proper consensus in the network are the key.
Data transfer problems whithin a smart grid. A smart grid is a very big deal: sensors, metering equipment, EMSs, building monitoring, etc. Theres alot of storage (DLs) and transfer in this environment, and it can all benefit from decentralized integrity. Let’s not even talk about introducing a new energy source in a smart grid, or extending a microgrid by commercial means.
Commercial aspects in localized P2P energy trading. Local energy marketplaces I think is the official buzzword. This is too obvious.
Billing. Well, I don’t need to explain this one, do I?
More dynamic markets in general (not the P2P ones). A smart contract can help in switching providers with the speed of light. Now this is can be good nes even for centralized grids such as ours.
Resource sharing in residential areas. With or W/O a microgrid infrastructure, residential resource sharing (Alternative energy producing infrastructure such as solar panels, EV Charging Stations, etc) can be shared in a more trustworthy environment if equimpents can make use of proper DLs

Now, in terms of the energy market & trading, OMG. I don’t have enough knowledge to even start to scratch that subject, but hey, that’s just another probable area of blockchain in energy.

P.S. the featured image is a representation of the “metil(1R,2R,3S,5S)-3-(benzoiloxi)-8-metil-8-azabiciclo[3.2.1]octane-2-carboxilat” aka “cocaine” molecule. It’s supposed to give you stimuli that you interpret as energy….or so I’ve heard.

Designing for critical privacy and data protection systems (I.5) – homomorphic secret sharing

Last time I have talked about some of the factors that influenced the evolution of privacy-preserving technologies.

I wanted to touch base with some of the technologies emerging from the impact of these factors and talk about some of the challenges that they come with.

After a discussion about e-differential privacy, I promised you a little discussion about homomorphic encryption.

There is a small detour that I find myself obligated to take. This is due to the latest circumstances of the SARS-CoV-2 outbreak: I want to split this discussion in two parts, and start with a little discussion about homomorphic secret sharing before I go into sharing my experience about adopting the homomorphic encryption.

What?! Why?

In the last article, I argued that one of the drivers for adopting new privacy mechanisms is: “The digitalization of the citizen facing services of nation-states. (stuff like e-voting, that I really advocate against)”

Well, sometime after the SARS-CoV-2 will be gone (a long time from today) I foresee a future where this kind of services will be more and more adopted. One of the areas where citizen facing services of nation-states will be digitalized is e-voting – e-voting within the parliament, for democratic elections, etc. I briefly mentioned last time that I am really against this. At least for now, given the status quo of the research in this area.

Let me explain a little bit the trouble with e-voting

Starting with a question: Why do you trust the people counting your vote?

[…annoying pause…]

A good answer here, could be:

Because all the parties having a stake in the elections have people counting. The counting is not done by a single ‘neutral’ authority.
Because, given the above statement, I can see my vote from the moment that I printed it, to the moment I cast it
Because your vote must be a secret, so that you cannot be blackmailed or paid to vote in a certain way – and there are some mechanisms for that
Because there is no – or little corruption in your country, and you don’t have a Dragnea (convicted for election fraud) pushing any buttons

You can see that in an electronic environment, this is hardly the case. Here, in an electronic environment, if you have a Dragnea, you are shot and buried. Here, in an electronic environment you:

Cannot see your vote since the moment you have printed (or pushed the button) to the moment of casting – anyone could see it
Cannot easily make sure that your vote is a secret. Once you act upon your vote and it is encrypted somehow, you have no way of knowing what you voted – it became a secret. So there is the trouble with that.
Further more, assuming conventional encryption, there are master keys that can be easily compromised by an evil Dragnea.
Auditing such a system involves an extremely high and particular level ofexpertise, and any of the parties having a stake in the election would really have trouble finding people willing to take the risk of doing that for them. This is an extreme sensitive matter.

There is a research area concerned with tackling these issues. It is called “End-To-End Verifiable Voting Systems”.

End-To-End Verifiable Voting Systems

Basically, tackling these problems for e-voting systems means transforming an electronic environment for voting in such a manner that it can, at least handle the standards of non e-voting systems, and then add some specific electronic mumbo-jumbo to it, and make it available in a ‘pandemic environment’. [Oh my God, I’ve just said that, pandemic environment…]

The main transformation is: I, as a voter, must be able to act a secret vote up to casting it, and make sure my vote is accounted for, properly.

Homomorphic secret sharing

It would be wonderful if, while addressing the trust in the counting of the votes problem we would have a way of casting an encrypted vote, but still be able to count it even if it is encrypted. Well this can be done.

To my knowledge today, the most effective and advanced technology that can be used here is homomorphic encryption, and, more precise, a small subset of HE, called homomorphic secret sharing.

Homomorphic secret sharing is a secret sharing algorithm where the secret is encrypted using homomorphic encryption. In a nutshell homomorphic encryption is a type of encryption where you can do computations on the ciphertext – that is compute stuff directly on encrypted data, with no prior decryption. For example: in some HE schemes an encryption of a 5 plus an encryption of a 2 is an encryption of a 7. Hooray.

Bear in mind, the mathematics behind all this is pretty complex. I would not call it scary, but close enough. However, there are smart people that are working on, and providing some, out-of-the-box libraries that software developers can use so that they can embed HE in their product. I would like to mention jus two here: Microsoft SEAL and PALISADE (backed by DARPA). Don’t get me wrong, today, you still have to know some mathematical tricks if you want to embed, HE in your software, but the really heavy part is done by these heroes that are providing these libraries.

Decentralized voting protocols using homomorphic secret sharing

In the next article I will talk about the challenges that you will face if you are trying to embed HE in your product, but until then, if you want to get a glimpse about the complexity, I will just go ahead and detail a decentralized voting protocol that uses homomorphic secret sharing.

Assume you have a simple vote (yes/no) – no overkill for now
Assume you have some authorities that will ‘count’ the votes. – number of authorities noted as A
Assume you have N voters

Each authority will generate a public key. Anumber. Xa
Each voter encodes his vote in a polynomial Pn, with the degree A-1 (number of authorities -1) and the constant term an encoding of the vote (for this case +1 for yes and -1 for no) all other coefs are random.
Each voter computes the value of his polynomial (Pn) – and thus his vote – at each authority public key Pn(Xa).
1. K points are produced, they are pieces of the vote.
1. Only if you know all the points you can figure out the Pn, and thus the vote. This is the decentralization part.
Voter sends each authority the value computed using its key only
Thus, each authority finds itself impossible to find how each user voted, as it does not have enough computed values – only has one.
After all votes have been casted, each authority computes and publishes a sum (Sa) of the received values.
Thus, a new polynomial is born (coefs are the Sa sums) with the constant term being the sum of all votes. If it is negative the result is yes, and vice versa.

If you had troubles following the secret sharing algorithm, don’t worry, you’re not alone. Here’s a helper illustration:

However, there are still problems:

Still, the voter cannot be sure that his/hers vote is properly casted
The authorities cannot be sure that a malicious voter did not computed his polynomial with a -100 constant, such that a single cast would count for 100 negative votes.
The homomorphic secret sharing does not even touch the other problems of voting systems, only the secrecy and the trust are tackled.

The challenges

See, you still have to know a little bit about polynomials and interpolation to be able to use this in your software.

The crazy part is that, in homomorphic encryption terms, homomorphic secret sharing is one of the simplest challenges.

Don’t worry though, in my next article I will show you some neat library (Microsoft SEAL), share my experience with you, and give you some tips and tricks for the moment when you will try to adopt this.

Until next time, remember: don’t take anything for granted.

Designing for critical privacy and data protection systems (I)

Mind the factors

Lately, I’ve been doing some work in the area of cryptography and enterprise scale data protection and privacy. And so, it hit me: things are a lot different than they used to be, and they are changing fast. It seems that things are changing towards a more secure environment, with stronger DP and privacy requirements and it also seems that these changes are widely adopted. Somehow, I am happy about it. Somehow, I am worried.

Before I go a little deeper into the topic of how to design for critical privacy and DP systems, let me just enumerate three of the factors that are responsible for generating the changes that we are witnessing:

The evolving worldwide regulation and technology adoption started by EU 2016/679 regulation (a.k.a. GDPR)
The unimaginable progress we are covering in terms of big data analysis and ML
The digitalization of the citizen facing services of nation-states. (stuff like e-voting, that I really advocate against)

I don’t want to cover in-depth the way I see each factor influencing the privacy and DP landscape, but, as we go on, I just want you to have these three factors in mind. Mind the factors.

Emerging technologies

Talking about each concept and technology that is gaining momentum in this context is absolutely impossible. So, I choose to talk about two of the most challenging ones. Or, at least the ones that I perceive as being the most challenging: this is going to be a two episodes series about Differential Privacy and Homomorphic Encryption.

Differential privacy. e-Differential Privacy.

Differential Privacy, in a nutshell, from a space-station view, is a mathematical way of ensuring that reconstruction attacks are not possible at the present or future time.

Mathematical what? Reconstruct what? Time what? Let me give you a textbook example:

Assume we know the following about a group of people:

There are 7 people with the median age of 30 and the mean of 38.

4 are females with the median of 30 and the mean of 33.5

4 love sugar with the median of 51 and a mean of 48.5

3 sugar lovers are females with the median 36 and the mean 36.6

Challenge: give me the: age, sex, sugar preference and marital status of each individual.

Solution:

1. 8, female, sugar, not married

2. 18, male, no sugar, not married

3. 24, female, no sugar, not married

4. 30, male, no sugar, married

5. 36, female, sugar, married

6, 66, female, sugar, married

7. 84, male, sugar, married

Basically, a reconstruction attack for such a scenario involves finding peaks of plausibility in a plausibility versus probability plot. It goes something like this:

You can start brute forcing all the combinations of the seven participants. Considering all the features except age (so, gender, sugar preference, marital) you have 7^8= 5764801 possibilities, but all have roughly the same plausibility. So a possibility / plausibility plot, looks something like this

See, there does not seem to be any peaks in plausibility. But, once we factor in the age, well, things change. For example, although possible to have a 150 years old person, it is very implausible. Furthermore, it is more plausible to have an older individual married than a younger one, and so on. So, if we factor in age plausibility, a graph looks more like this:

See, there’s a peak of plausibility. That is most likely our solution. Now, if our published statistics are a little skewed. Say, we introduce just enough noise into them such that the impact is minimum for science, and we eliminate the unnecessary ones (if this can be done) then, a reconstruction attack is almost impossible. The purpose is to flatten, as much as possible, the graph above.

Now, to be fair, in our stretched-out textbook example, there’s no need to do the brute-force-assumption plausibility plot. Because the Mean and Median are published for each subset of results, you can simply write a deterministic equation system and solve for the actual solution.

Imagine you, as an attacker possess some external knowledge about your target from an external source. This external source may be an historical publishing over the same set of data, or a different data source altogether. This makes your reconstruction job easier.

e-Differential Privacy systems have a way of defining a privacy loss (i.e. a quantitative measure of the increase in the plausibility plot) Also, these systems define a privacy budget. And this is one of the real treasures of this math. You can make sure that, over time, you are not making the reconstruction attacks easier.

This stuff gained momentum as the US census bureau got the word out the they are using it, and also encouraged people to ask enterprises that own their data to use it.

So, as a software architect, how do I get ready for this?

First, at the moment, there are no out-of-the box solutions that can give you e-Differential Privacy for your data. If this is a requirement for you, you are most probably going to work with some data scientists / math degree that are going to tell you exactly what will be a measure a privacy loss for the features in your data. At least that is what I did 😊 Once they are defined you have to be ready to implement those.

There is a common pattern you can adopt. A proxy, a privacy guard:

You are smart enough to realize that CLEAN data means that some acceptable noise is introduced, such that the privacy budget is not greatly, if at all, impacted.

Challenges

If it was easy, everyone would do it, but it’s not, so suck it.

First, you and your team must be ready to understand what a highly trained math scientist is talking about. Get resources for that.

Second, you have to be careful, as an architect, to have formal definitions throughout your applications for the two concepts enumerated above: privacy budget, and privacy loss.

Third, in both my experience and in the textbook ongoing research, the database must contain the absolute raw data, including historic data if needed. This poses another security challenge: you don’t want to be fancy about using complicated math to protect your data while being vulnerable to a direct database attack. Something stupid like injection attacks have no place here. You can see now that the diagram above is oversimplified. It lacks a ton of proxies, security controls, DMZs and whatnot. Don’t make the same mistake I did and try to hide some data from the privacy guard, your life will be a misery.

Fourth, Be extremely careful about documenting this. It is not rare that software ecosystems change purpose, and the tend to be used where they are not supposed to. It may happen that such an ecosystem, with time, gets to be directly used for scientific research, from behind the privacy guard. That might not be acceptable. You know, scientists don’t like to have noisy data. So I’ve heard, I’m not a scientist.

That’s all for now.

In the second part we’re going to talk a little bit about the time I used Homomorphic Encryption. A mother****ing monster for me.

Stay safe!

Ordering the ubiquitous

Recently, I was about to tell a joke that started like this:

“Two guys walk into a bar, the first one says… “

Someone went all anti-climactic on the storyteller (me), stopping him (me), asking: how do you know which one is the first one?

He was not, at all, trained in mathematics. He does not know that, when order is not important, order can, and often must, be imposed.

I did not bother to explain this, I just rephrased:

“Two guys walk into a bar, one of them says… “

I am a good storyteller, after all.

This got me thinking:

A random first story

I have talked about how, back in 2012-2013, I had had implemented, from scratch, a mechanism for single execution of a mission critical operation. This was before blockchain was KBOOM. Blockchain existed, but I only knew a single and remote person that knew something about blockchain. Our team chosen to not use this relatively new technology at that point.

Last year, 2018, I was requested by my client to lead the rework of this system, but now, using blockchain. O yeah! We’ve got it done some months ago. This turned out to be the last side-project I took. For this year at least. I have my first child being born soon, and I need a break from these challenges. Anyway, I divert, back on track: single execution, blockchain, and a challenge accompanied by a frustration. We were a team of six people implementing this. Before starting, I wanted to make sure that everyone is on the same page in terms of what we do, and what blockchain is. Turns out, that while explaining bits of the blockchain, some people had troubles understanding the most basic concept: consensus and consensus algorithms. I went all haywire trying to explain concepts like: termination, integrity, agreement and fault tolerant consensus. I immediately remembered that when I was young, some very smart guy, forced me to read a paper called: „Time, Clocks, and the Ordering of Events in a Distributed System” – by Leslie Lamport. I mandated that this shall be read prior to my explanation. Everything went smooth from there on.

Be lucky. It’s your responsibility now.

Part of my daily job is working with the cloud. Large scale, small scale, simple, complicated, doing cloud design, develop cloud solutions, teaching, consulting and whatnot. While doing all this for some time now, I realized that a certain generation of technical, and otherwise very well-trained people, mostly in the software development area, has a very big problem in working with distributed systems over the cloud.

I could not understand this for years. It just did not compute. Why was this happening?

Well, turns out, some people were just not fortunate enough to have a smart guy around while “growing up”, that was able to teach them the basics of distributed computing.

I have repeated the experiment from the first story 9 additional times. Each time the same result. It’s like a veil was unveiled for some people.

So, I dare you, I double dare you, If you feel you don’t quite grasp software developing solutions in a distributed environment, have a read on the same paper. It is a masterpiece from 1976-1977, I promise you.

Cloud is dead

Yes. Cloud is dead. We now have ubiquitous computing. And, to be honest, this is close to be dead soon enough. A non-distributed environment does not exist anymore. I am not sure it ever did.

Be good!

Pragmatic Homomorphic Encryption

Hi again!

Since you’re here, I believe that you have a general idea about what homomorphic encryption is. If, however you are a little confused, here it is in a nutshell: you can do data processing directly on encrypted data. E.G. An encryption of a 5 multiplied by an encryption of a 2 is an encryption of a 10. Tadaaa!

This is pure magic for privacy. Especially with this hype that is happening now with all the data leaks, and new privacy regulation, and old privacy regulation, and s**t. Essentially, what you can do with this is very close to the holy grail of privacy: complete confidential computing, process data that is already encrypted, without the decryption key. Assuming data protection in transit is already done. See picture bellow:

Quick note here, most of the homomorphic schemes (BFV/CKKS/blabla..) use a public/private scheme for encrypting/decryption of data.

Now, I have been fortunate enough to work, in the past year, on a side project involving a lot of homomorphic encryption. I was using Microsoft SEAL and it was great. I am not going to talk about the math behind this type of encryption, not going to talk about the Microsoft SEAL library (although I consider it excellent), not going to talk about the noise-propagation problem in this kind of encryption.

I am, however, going to talk about a common pitfall that I have seen, and that is worrying. This pitfall is concerning the integrity of the result processing. Or, to be more precise, attacking the integrity of the expected result of processing.

Some Example

Let me give you an example: Assume you have an IoT solution that is monitoring some oil rigs. The IoT devices encrypt the data that is collected by them, then sends it to a central service for statistical analysis. The central service does the processing and provides an API for some other clients used by top management.

(This is just an example. I am not saying I did exactly this. It would be $tupid to break an NDA and be so open about it.)

If I, as an attacker compromise the service that is doing the statistical analysis, I cannot see the real data sent by the sensors. However, I could mess with it a little. I could, for instance, make sure that the statistical analysis returned by the API is rigged, that it shows whatever I want it to show.

I am not saying that I am able to change the input data. After all, I as an attacker do not have the key used for encryption, so that I am not able to encrypt new data in the series. I just go ahead and alter the result.

It seems obvious that you should protect such a system against impersonation/MitM/spoofing attacks. Well. Apparently, it is not that obvious.

The Trouble

While implementing this project, I got in touch with various teams that were working with homomorphic encryption, and it seems that there was a recurring issue. The problem is that the team that is implementing such a solution, usually is made up of experienced (at least) developers that have a solid knowledge of math / cryptography. But it is not their role to handle the overall security of the system.

The team that is responsible for the overall security of the system, is unfortunately, often decoupled with the details of a project that is under development. What do they “know” about the project? Homomorphic encryption? Well, that is cool, data integrity is handled by encryption, so why put any extra effort into that?

Please, please, do not overlook basic security just because some pretty neat researchers made a breakthrough regarding the efficiently of implementing a revolutionary encryption scheme. Revolutionary does not mean lazy. And FYI, a Full Homomorphic Encryption Scheme has been theorized since 1978.

To be fair play, I want to mention another library that is good at doing homomorphic encryption, PALISADE. I only have some production experience with Microsoft SEAL, and thus, I prefer it 😊

Be safe!