Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2010/03/05/crypto-fear.html

Boy, do I hate it when a
FLOSS
project is given a hard time unfairly. I was this morning greeted
with news
from many
places that OpenSSL, one of the
most common FLOSS software libraries used for cryptography, was
somehow severely vulnerable.

I had a hunch what was going on. I quickly downloaded
a copy
of the academic paper that was cited as the sole source for the
story and read it. As I feared, OpenSSL was getting some bad press
unfairly. One must really read this academic computer science article
in the context it was written; most commenting about this paper
probably did not.

First of all, I don’t claim to be an expert on cryptography, and I
think my knowledge level to opine on this subject remains limited to a
little blog post like this and nothing more. Between college and
graduate school, I worked as a system administrator focusing on network
security. While a computer science graduate student, I did take two
cryptography courses, two theory of computation courses, and one class
on complexity theory⁰. So, when
compared to the general population I probably am an expert, but compared to
people who actually work in cryptography regularly, I’m clearly a
novice. However, I suspect many who have hitherto opined about this
academic article to declare this severe vulnerability have even
less knowledge than I do on the subject.

This article, of course, wasn’t written for novices like me, and
certainly not for the general public nor the technology press. It was
written by and for professional researchers who spend much time each
week reading dozens of these academic papers, a task I haven’t done
since graduate school. Indeed, the paper is written in a style I know
well; my “welcome to CS graduate school” seminar in 1997
covered the format well.

The first thing you have to note about such papers is that informed
readers generally ignore the parts that a newbie is most likely focus
on: the Abstract, Introduction and Conclusion sections. These sections
are promotional materials; they are equivalent to a sales brochure
selling you on how important and groundbreaking the research is. Some
research is groundbreaking, of course, but most is an incremental step
forward toward understanding some theoretical concept, or some report
about an isolated but interesting experimental finding.

Unfortunately, these promotional parts of the paper are the sections
that focus on the negative implications for OpenSSL. In the rest of the
paper, OpenSSL is merely the software component of the experiment
equipment. They likely could have used GNU TLS or any other
implementation of RSA taken from a book on
cryptography¹. But this fact
is not even the primary reason that this article isn’t really that big
of a deal for daily use of cryptography.

The experiment described in the paper is very difficult to reproduce.
You have to cause very subtle faults in computation at specific times.
As I understand it, they had to assemble a specialized hardware copy of
a SPARC-based GNU/Linux environment to accomplish the experiment.

Next, the data generated during the run of the software on the
specially-constructed faulty hardware must be collected and operated
upon by a parallel processing computing environment over the course of
many hours. If it turns out all the needed data was gathered, the
output of this whole process is the private RSA key.

The details of the fault generation process deserve special mention.
Very specific faults have to occur, and they can’t occur such that any
other parts of the computation (such as, say, the normal running of the
operating system) are interrupted or corrupted. This is somewhat
straightforward to get done in a lab environment, but accomplishing it
in a production situation would be impractical and improbable. It would
also usually require physical access to the hardware holding the private
key. Such physical access would, of course, probably give you the
private key anyway by simply copying it off the hard drive or out of
RAM!

This is interesting research, and it does suggest some changes that
might be useful. For example, if it doesn’t slow a system down too
much, the integrity of RSA signatures should be verified, on a closely
controlled proxy unit with a separate CPU, before sending out to a wider
audience. But even that would be a process only for the most paranoid.
If faults are occurring on production hardware enough to generate the
bad computations this cracking process relies on, likely something else
will go wrong on the hardware too and it will be declared generally
unusable for production before an interloper could gather enough data to
crack the key. Thus, another useful change to make based on this
finding is to disable and discard RSA keys that were in use on
production hardware that went faulty.

Finally, I think this article does completely convince me that I would
never want to run any RSA computations on a system where the CPU was
emulated. Causing faults in an emulated CPU would only require changes
to the emulation software, and could be done with careful precision to
detect when an RSA-related computation was happening, and only give the
faulty result on those occasions. I’ve never heard of anyone running
production cryptography on an emulated CPU, since it would be too slow,
and virtualization technologies like Xen, KVM, and QEMU all
pass-through CPU instructions directly to hardware (for speed reasons)
when the virtualized guest matches the hardware architecture of the
host.

The point, however, is that proper description of the dangers of a
“security vulnerability” requires more than a single bit
field. Some security vulnerabilities are much worse than others. This
one is substantially closer to the “oh, that’s cute” end of
the spectrum, not the “ZOMG, everyone’s going to experience
identity theft tomorrow” side.

⁰Many casual
users don’t realize that cryptography — the stuff that secures your
networked data from unwanted viewers — isn’t about math problems
that are unsolvable. In fact, it’s often based on math problems that are
trivially solvable, but take a very long time to solve. This is why
algorithmic complexity questions are central to the question of
cryptographic security.

¹ I’m
oversimplifying a bit here. A key factor in the paper appears to be the
linear time algorithm used to compute cryptographic digital signatures,
and the fact that the signatures aren’t verified for integrity before
being deployed. I suspect, though, that just about any RSA system is
going to do this. (Although I do usually test the integrity of my GnuPG
signatures before sending them out, I do this as a user by hand).

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2010/03/05/crypto-fear.html

Boy, do I hate it when a
FLOSS
project is given a hard time unfairly. I was this morning greeted
with news
from many
places that OpenSSL, one of the
most common FLOSS software libraries used for cryptography, was
somehow severely vulnerable.

I had a hunch what was going on. I quickly downloaded
a copy
of the academic paper that was cited as the sole source for the
story and read it. As I feared, OpenSSL was getting some bad press
unfairly. One must really read this academic computer science article
in the context it was written; most commenting about this paper
probably did not.

First of all, I don’t claim to be an expert on cryptography, and I
think my knowledge level to opine on this subject remains limited to a
little blog post like this and nothing more. Between college and
graduate school, I worked as a system administrator focusing on network
security. While a computer science graduate student, I did take two
cryptography courses, two theory of computation courses, and one class
on complexity theory⁰. So, when
compared to the general population I probably am an expert, but compared to
people who actually work in cryptography regularly, I’m clearly a
novice. However, I suspect many who have hitherto opined about this
academic article to declare this severe vulnerability have even
less knowledge than I do on the subject.

This article, of course, wasn’t written for novices like me, and
certainly not for the general public nor the technology press. It was
written by and for professional researchers who spend much time each
week reading dozens of these academic papers, a task I haven’t done
since graduate school. Indeed, the paper is written in a style I know
well; my “welcome to CS graduate school” seminar in 1997
covered the format well.

The first thing you have to note about such papers is that informed
readers generally ignore the parts that a newbie is most likely focus
on: the Abstract, Introduction and Conclusion sections. These sections
are promotional materials; they are equivalent to a sales brochure
selling you on how important and groundbreaking the research is. Some
research is groundbreaking, of course, but most is an incremental step
forward toward understanding some theoretical concept, or some report
about an isolated but interesting experimental finding.

Unfortunately, these promotional parts of the paper are the sections
that focus on the negative implications for OpenSSL. In the rest of the
paper, OpenSSL is merely the software component of the experiment
equipment. They likely could have used GNU TLS or any other
implementation of RSA taken from a book on
cryptography¹. But this fact
is not even the primary reason that this article isn’t really that big
of a deal for daily use of cryptography.

The experiment described in the paper is very difficult to reproduce.
You have to cause very subtle faults in computation at specific times.
As I understand it, they had to assemble a specialized hardware copy of
a SPARC-based GNU/Linux environment to accomplish the experiment.

Next, the data generated during the run of the software on the
specially-constructed faulty hardware must be collected and operated
upon by a parallel processing computing environment over the course of
many hours. If it turns out all the needed data was gathered, the
output of this whole process is the private RSA key.

The details of the fault generation process deserve special mention.
Very specific faults have to occur, and they can’t occur such that any
other parts of the computation (such as, say, the normal running of the
operating system) are interrupted or corrupted. This is somewhat
straightforward to get done in a lab environment, but accomplishing it
in a production situation would be impractical and improbable. It would
also usually require physical access to the hardware holding the private
key. Such physical access would, of course, probably give you the
private key anyway by simply copying it off the hard drive or out of
RAM!

This is interesting research, and it does suggest some changes that
might be useful. For example, if it doesn’t slow a system down too
much, the integrity of RSA signatures should be verified, on a closely
controlled proxy unit with a separate CPU, before sending out to a wider
audience. But even that would be a process only for the most paranoid.
If faults are occurring on production hardware enough to generate the
bad computations this cracking process relies on, likely something else
will go wrong on the hardware too and it will be declared generally
unusable for production before an interloper could gather enough data to
crack the key. Thus, another useful change to make based on this
finding is to disable and discard RSA keys that were in use on
production hardware that went faulty.

Finally, I think this article does completely convince me that I would
never want to run any RSA computations on a system where the CPU was
emulated. Causing faults in an emulated CPU would only require changes
to the emulation software, and could be done with careful precision to
detect when an RSA-related computation was happening, and only give the
faulty result on those occasions. I’ve never heard of anyone running
production cryptography on an emulated CPU, since it would be too slow,
and virtualization technologies like Xen, KVM, and QEMU all
pass-through CPU instructions directly to hardware (for speed reasons)
when the virtualized guest matches the hardware architecture of the
host.

The point, however, is that proper description of the dangers of a
“security vulnerability” requires more than a single bit
field. Some security vulnerabilities are much worse than others. This
one is substantially closer to the “oh, that’s cute” end of
the spectrum, not the “ZOMG, everyone’s going to experience
identity theft tomorrow” side.

⁰Many casual
users don’t realize that cryptography — the stuff that secures your
networked data from unwanted viewers — isn’t about math problems
that are unsolvable. In fact, it’s often based on math problems that are
trivially solvable, but take a very long time to solve. This is why
algorithmic complexity questions are central to the question of
cryptographic security.

¹ I’m
oversimplifying a bit here. A key factor in the paper appears to be the
linear time algorithm used to compute cryptographic digital signatures,
and the fact that the signatures aren’t verified for integrity before
being deployed. I suspect, though, that just about any RSA system is
going to do this. (Although I do usually test the integrity of my GnuPG
signatures before sending them out, I do this as a user by hand).

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2010/03/05/crypto-fear.html

Boy, do I hate it when a
FLOSS
project is given a hard time unfairly. I was this morning greeted
with news
from many
places that OpenSSL, one of the
most common FLOSS software libraries used for cryptography, was
somehow severely vulnerable.

I had a hunch what was going on. I quickly downloaded
a copy
of the academic paper that was cited as the sole source for the
story and read it. As I feared, OpenSSL was getting some bad press
unfairly. One must really read this academic computer science article
in the context it was written; most commenting about this paper
probably did not.

First of all, I don’t claim to be an expert on cryptography, and I
think my knowledge level to opine on this subject remains limited to a
little blog post like this and nothing more. Between college and
graduate school, I worked as a system administrator focusing on network
security. While a computer science graduate student, I did take two
cryptography courses, two theory of computation courses, and one class
on complexity theory⁰. So, when
compared to the general population I probably am an expert, but compared to
people who actually work in cryptography regularly, I’m clearly a
novice. However, I suspect many who have hitherto opined about this
academic article to declare this severe vulnerability have even
less knowledge than I do on the subject.

This article, of course, wasn’t written for novices like me, and
certainly not for the general public nor the technology press. It was
written by and for professional researchers who spend much time each
week reading dozens of these academic papers, a task I haven’t done
since graduate school. Indeed, the paper is written in a style I know
well; my “welcome to CS graduate school” seminar in 1997
covered the format well.

The first thing you have to note about such papers is that informed
readers generally ignore the parts that a newbie is most likely focus
on: the Abstract, Introduction and Conclusion sections. These sections
are promotional materials; they are equivalent to a sales brochure
selling you on how important and groundbreaking the research is. Some
research is groundbreaking, of course, but most is an incremental step
forward toward understanding some theoretical concept, or some report
about an isolated but interesting experimental finding.

Unfortunately, these promotional parts of the paper are the sections
that focus on the negative implications for OpenSSL. In the rest of the
paper, OpenSSL is merely the software component of the experiment
equipment. They likely could have used GNU TLS or any other
implementation of RSA taken from a book on
cryptography¹. But this fact
is not even the primary reason that this article isn’t really that big
of a deal for daily use of cryptography.

The experiment described in the paper is very difficult to reproduce.
You have to cause very subtle faults in computation at specific times.
As I understand it, they had to assemble a specialized hardware copy of
a SPARC-based GNU/Linux environment to accomplish the experiment.

Next, the data generated during the run of the software on the
specially-constructed faulty hardware must be collected and operated
upon by a parallel processing computing environment over the course of
many hours. If it turns out all the needed data was gathered, the
output of this whole process is the private RSA key.

The details of the fault generation process deserve special mention.
Very specific faults have to occur, and they can’t occur such that any
other parts of the computation (such as, say, the normal running of the
operating system) are interrupted or corrupted. This is somewhat
straightforward to get done in a lab environment, but accomplishing it
in a production situation would be impractical and improbable. It would
also usually require physical access to the hardware holding the private
key. Such physical access would, of course, probably give you the
private key anyway by simply copying it off the hard drive or out of
RAM!

This is interesting research, and it does suggest some changes that
might be useful. For example, if it doesn’t slow a system down too
much, the integrity of RSA signatures should be verified, on a closely
controlled proxy unit with a separate CPU, before sending out to a wider
audience. But even that would be a process only for the most paranoid.
If faults are occurring on production hardware enough to generate the
bad computations this cracking process relies on, likely something else
will go wrong on the hardware too and it will be declared generally
unusable for production before an interloper could gather enough data to
crack the key. Thus, another useful change to make based on this
finding is to disable and discard RSA keys that were in use on
production hardware that went faulty.

Finally, I think this article does completely convince me that I would
never want to run any RSA computations on a system where the CPU was
emulated. Causing faults in an emulated CPU would only require changes
to the emulation software, and could be done with careful precision to
detect when an RSA-related computation was happening, and only give the
faulty result on those occasions. I’ve never heard of anyone running
production cryptography on an emulated CPU, since it would be too slow,
and virtualization technologies like Xen, KVM, and QEMU all
pass-through CPU instructions directly to hardware (for speed reasons)
when the virtualized guest matches the hardware architecture of the
host.

The point, however, is that proper description of the dangers of a
“security vulnerability” requires more than a single bit
field. Some security vulnerabilities are much worse than others. This
one is substantially closer to the “oh, that’s cute” end of
the spectrum, not the “ZOMG, everyone’s going to experience
identity theft tomorrow” side.

⁰Many casual
users don’t realize that cryptography — the stuff that secures your
networked data from unwanted viewers — isn’t about math problems
that are unsolvable. In fact, it’s often based on math problems that are
trivially solvable, but take a very long time to solve. This is why
algorithmic complexity questions are central to the question of
cryptographic security.

¹ I’m
oversimplifying a bit here. A key factor in the paper appears to be the
linear time algorithm used to compute cryptographic digital signatures,
and the fact that the signatures aren’t verified for integrity before
being deployed. I suspect, though, that just about any RSA system is
going to do this. (Although I do usually test the integrity of my GnuPG
signatures before sending them out, I do this as a user by hand).

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2010/03/05/crypto-fear.html

Boy, do I hate it when a
FLOSS
project is given a hard time unfairly. I was this morning greeted
with news
from many
places that OpenSSL, one of the
most common FLOSS software libraries used for cryptography, was
somehow severely vulnerable.

I had a hunch what was going on. I quickly downloaded
a copy
of the academic paper that was cited as the sole source for the
story and read it. As I feared, OpenSSL was getting some bad press
unfairly. One must really read this academic computer science article
in the context it was written; most commenting about this paper
probably did not.

First of all, I don’t claim to be an expert on cryptography, and I
think my knowledge level to opine on this subject remains limited to a
little blog post like this and nothing more. Between college and
graduate school, I worked as a system administrator focusing on network
security. While a computer science graduate student, I did take two
cryptography courses, two theory of computation courses, and one class
on complexity theory⁰. So, when
compared to the general population I probably am an expert, but compared to
people who actually work in cryptography regularly, I’m clearly a
novice. However, I suspect many who have hitherto opined about this
academic article to declare this severe vulnerability have even
less knowledge than I do on the subject.

This article, of course, wasn’t written for novices like me, and
certainly not for the general public nor the technology press. It was
written by and for professional researchers who spend much time each
week reading dozens of these academic papers, a task I haven’t done
since graduate school. Indeed, the paper is written in a style I know
well; my “welcome to CS graduate school” seminar in 1997
covered the format well.

The first thing you have to note about such papers is that informed
readers generally ignore the parts that a newbie is most likely focus
on: the Abstract, Introduction and Conclusion sections. These sections
are promotional materials; they are equivalent to a sales brochure
selling you on how important and groundbreaking the research is. Some
research is groundbreaking, of course, but most is an incremental step
forward toward understanding some theoretical concept, or some report
about an isolated but interesting experimental finding.

Unfortunately, these promotional parts of the paper are the sections
that focus on the negative implications for OpenSSL. In the rest of the
paper, OpenSSL is merely the software component of the experiment
equipment. They likely could have used GNU TLS or any other
implementation of RSA taken from a book on
cryptography¹. But this fact
is not even the primary reason that this article isn’t really that big
of a deal for daily use of cryptography.

The experiment described in the paper is very difficult to reproduce.
You have to cause very subtle faults in computation at specific times.
As I understand it, they had to assemble a specialized hardware copy of
a SPARC-based GNU/Linux environment to accomplish the experiment.

Next, the data generated during the run of the software on the
specially-constructed faulty hardware must be collected and operated
upon by a parallel processing computing environment over the course of
many hours. If it turns out all the needed data was gathered, the
output of this whole process is the private RSA key.

The details of the fault generation process deserve special mention.
Very specific faults have to occur, and they can’t occur such that any
other parts of the computation (such as, say, the normal running of the
operating system) are interrupted or corrupted. This is somewhat
straightforward to get done in a lab environment, but accomplishing it
in a production situation would be impractical and improbable. It would
also usually require physical access to the hardware holding the private
key. Such physical access would, of course, probably give you the
private key anyway by simply copying it off the hard drive or out of
RAM!

This is interesting research, and it does suggest some changes that
might be useful. For example, if it doesn’t slow a system down too
much, the integrity of RSA signatures should be verified, on a closely
controlled proxy unit with a separate CPU, before sending out to a wider
audience. But even that would be a process only for the most paranoid.
If faults are occurring on production hardware enough to generate the
bad computations this cracking process relies on, likely something else
will go wrong on the hardware too and it will be declared generally
unusable for production before an interloper could gather enough data to
crack the key. Thus, another useful change to make based on this
finding is to disable and discard RSA keys that were in use on
production hardware that went faulty.

Finally, I think this article does completely convince me that I would
never want to run any RSA computations on a system where the CPU was
emulated. Causing faults in an emulated CPU would only require changes
to the emulation software, and could be done with careful precision to
detect when an RSA-related computation was happening, and only give the
faulty result on those occasions. I’ve never heard of anyone running
production cryptography on an emulated CPU, since it would be too slow,
and virtualization technologies like Xen, KVM, and QEMU all
pass-through CPU instructions directly to hardware (for speed reasons)
when the virtualized guest matches the hardware architecture of the
host.

The point, however, is that proper description of the dangers of a
“security vulnerability” requires more than a single bit
field. Some security vulnerabilities are much worse than others. This
one is substantially closer to the “oh, that’s cute” end of
the spectrum, not the “ZOMG, everyone’s going to experience
identity theft tomorrow” side.

⁰Many casual
users don’t realize that cryptography — the stuff that secures your
networked data from unwanted viewers — isn’t about math problems
that are unsolvable. In fact, it’s often based on math problems that are
trivially solvable, but take a very long time to solve. This is why
algorithmic complexity questions are central to the question of
cryptographic security.

¹ I’m
oversimplifying a bit here. A key factor in the paper appears to be the
linear time algorithm used to compute cryptographic digital signatures,
and the fact that the signatures aren’t verified for integrity before
being deployed. I suspect, though, that just about any RSA system is
going to do this. (Although I do usually test the integrity of my GnuPG
signatures before sending them out, I do this as a user by hand).

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2010/03/05/crypto-fear.html

Boy, do I hate it when a
FLOSS
project is given a hard time unfairly. I was this morning greeted
with news
from many
places that OpenSSL, one of the
most common FLOSS software libraries used for cryptography, was
somehow severely vulnerable.

I had a hunch what was going on. I quickly downloaded
a copy
of the academic paper that was cited as the sole source for the
story and read it. As I feared, OpenSSL was getting some bad press
unfairly. One must really read this academic computer science article
in the context it was written; most commenting about this paper
probably did not.

First of all, I don’t claim to be an expert on cryptography, and I
think my knowledge level to opine on this subject remains limited to a
little blog post like this and nothing more. Between college and
graduate school, I worked as a system administrator focusing on network
security. While a computer science graduate student, I did take two
cryptography courses, two theory of computation courses, and one class
on complexity theory⁰. So, when
compared to the general population I probably am an expert, but compared to
people who actually work in cryptography regularly, I’m clearly a
novice. However, I suspect many who have hitherto opined about this
academic article to declare this severe vulnerability have even
less knowledge than I do on the subject.

This article, of course, wasn’t written for novices like me, and
certainly not for the general public nor the technology press. It was
written by and for professional researchers who spend much time each
week reading dozens of these academic papers, a task I haven’t done
since graduate school. Indeed, the paper is written in a style I know
well; my “welcome to CS graduate school” seminar in 1997
covered the format well.

The first thing you have to note about such papers is that informed
readers generally ignore the parts that a newbie is most likely focus
on: the Abstract, Introduction and Conclusion sections. These sections
are promotional materials; they are equivalent to a sales brochure
selling you on how important and groundbreaking the research is. Some
research is groundbreaking, of course, but most is an incremental step
forward toward understanding some theoretical concept, or some report
about an isolated but interesting experimental finding.

Unfortunately, these promotional parts of the paper are the sections
that focus on the negative implications for OpenSSL. In the rest of the
paper, OpenSSL is merely the software component of the experiment
equipment. They likely could have used GNU TLS or any other
implementation of RSA taken from a book on
cryptography¹. But this fact
is not even the primary reason that this article isn’t really that big
of a deal for daily use of cryptography.

The experiment described in the paper is very difficult to reproduce.
You have to cause very subtle faults in computation at specific times.
As I understand it, they had to assemble a specialized hardware copy of
a SPARC-based GNU/Linux environment to accomplish the experiment.

Next, the data generated during the run of the software on the
specially-constructed faulty hardware must be collected and operated
upon by a parallel processing computing environment over the course of
many hours. If it turns out all the needed data was gathered, the
output of this whole process is the private RSA key.

The details of the fault generation process deserve special mention.
Very specific faults have to occur, and they can’t occur such that any
other parts of the computation (such as, say, the normal running of the
operating system) are interrupted or corrupted. This is somewhat
straightforward to get done in a lab environment, but accomplishing it
in a production situation would be impractical and improbable. It would
also usually require physical access to the hardware holding the private
key. Such physical access would, of course, probably give you the
private key anyway by simply copying it off the hard drive or out of
RAM!

This is interesting research, and it does suggest some changes that
might be useful. For example, if it doesn’t slow a system down too
much, the integrity of RSA signatures should be verified, on a closely
controlled proxy unit with a separate CPU, before sending out to a wider
audience. But even that would be a process only for the most paranoid.
If faults are occurring on production hardware enough to generate the
bad computations this cracking process relies on, likely something else
will go wrong on the hardware too and it will be declared generally
unusable for production before an interloper could gather enough data to
crack the key. Thus, another useful change to make based on this
finding is to disable and discard RSA keys that were in use on
production hardware that went faulty.

Finally, I think this article does completely convince me that I would
never want to run any RSA computations on a system where the CPU was
emulated. Causing faults in an emulated CPU would only require changes
to the emulation software, and could be done with careful precision to
detect when an RSA-related computation was happening, and only give the
faulty result on those occasions. I’ve never heard of anyone running
production cryptography on an emulated CPU, since it would be too slow,
and virtualization technologies like Xen, KVM, and QEMU all
pass-through CPU instructions directly to hardware (for speed reasons)
when the virtualized guest matches the hardware architecture of the
host.

The point, however, is that proper description of the dangers of a
“security vulnerability” requires more than a single bit
field. Some security vulnerabilities are much worse than others. This
one is substantially closer to the “oh, that’s cute” end of
the spectrum, not the “ZOMG, everyone’s going to experience
identity theft tomorrow” side.

⁰Many casual
users don’t realize that cryptography — the stuff that secures your
networked data from unwanted viewers — isn’t about math problems
that are unsolvable. In fact, it’s often based on math problems that are
trivially solvable, but take a very long time to solve. This is why
algorithmic complexity questions are central to the question of
cryptographic security.

¹ I’m
oversimplifying a bit here. A key factor in the paper appears to be the
linear time algorithm used to compute cryptographic digital signatures,
and the fact that the signatures aren’t verified for integrity before
being deployed. I suspect, though, that just about any RSA system is
going to do this. (Although I do usually test the integrity of my GnuPG
signatures before sending them out, I do this as a user by hand).

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2010/03/05/crypto-fear.html

Boy, do I hate it when a
FLOSS
project is given a hard time unfairly. I was this morning greeted
with news
from many
places that OpenSSL, one of the
most common FLOSS software libraries used for cryptography, was
somehow severely vulnerable.

I had a hunch what was going on. I quickly downloaded
a copy
of the academic paper that was cited as the sole source for the
story and read it. As I feared, OpenSSL was getting some bad press
unfairly. One must really read this academic computer science article
in the context it was written; most commenting about this paper
probably did not.

First of all, I don’t claim to be an expert on cryptography, and I
think my knowledge level to opine on this subject remains limited to a
little blog post like this and nothing more. Between college and
graduate school, I worked as a system administrator focusing on network
security. While a computer science graduate student, I did take two
cryptography courses, two theory of computation courses, and one class
on complexity theory⁰. So, when
compared to the general population I probably am an expert, but compared to
people who actually work in cryptography regularly, I’m clearly a
novice. However, I suspect many who have hitherto opined about this
academic article to declare this severe vulnerability have even
less knowledge than I do on the subject.

This article, of course, wasn’t written for novices like me, and
certainly not for the general public nor the technology press. It was
written by and for professional researchers who spend much time each
week reading dozens of these academic papers, a task I haven’t done
since graduate school. Indeed, the paper is written in a style I know
well; my “welcome to CS graduate school” seminar in 1997
covered the format well.

The first thing you have to note about such papers is that informed
readers generally ignore the parts that a newbie is most likely focus
on: the Abstract, Introduction and Conclusion sections. These sections
are promotional materials; they are equivalent to a sales brochure
selling you on how important and groundbreaking the research is. Some
research is groundbreaking, of course, but most is an incremental step
forward toward understanding some theoretical concept, or some report
about an isolated but interesting experimental finding.

Unfortunately, these promotional parts of the paper are the sections
that focus on the negative implications for OpenSSL. In the rest of the
paper, OpenSSL is merely the software component of the experiment
equipment. They likely could have used GNU TLS or any other
implementation of RSA taken from a book on
cryptography¹. But this fact
is not even the primary reason that this article isn’t really that big
of a deal for daily use of cryptography.

The experiment described in the paper is very difficult to reproduce.
You have to cause very subtle faults in computation at specific times.
As I understand it, they had to assemble a specialized hardware copy of
a SPARC-based GNU/Linux environment to accomplish the experiment.

Next, the data generated during the run of the software on the
specially-constructed faulty hardware must be collected and operated
upon by a parallel processing computing environment over the course of
many hours. If it turns out all the needed data was gathered, the
output of this whole process is the private RSA key.

The details of the fault generation process deserve special mention.
Very specific faults have to occur, and they can’t occur such that any
other parts of the computation (such as, say, the normal running of the
operating system) are interrupted or corrupted. This is somewhat
straightforward to get done in a lab environment, but accomplishing it
in a production situation would be impractical and improbable. It would
also usually require physical access to the hardware holding the private
key. Such physical access would, of course, probably give you the
private key anyway by simply copying it off the hard drive or out of
RAM!

This is interesting research, and it does suggest some changes that
might be useful. For example, if it doesn’t slow a system down too
much, the integrity of RSA signatures should be verified, on a closely
controlled proxy unit with a separate CPU, before sending out to a wider
audience. But even that would be a process only for the most paranoid.
If faults are occurring on production hardware enough to generate the
bad computations this cracking process relies on, likely something else
will go wrong on the hardware too and it will be declared generally
unusable for production before an interloper could gather enough data to
crack the key. Thus, another useful change to make based on this
finding is to disable and discard RSA keys that were in use on
production hardware that went faulty.

Finally, I think this article does completely convince me that I would
never want to run any RSA computations on a system where the CPU was
emulated. Causing faults in an emulated CPU would only require changes
to the emulation software, and could be done with careful precision to
detect when an RSA-related computation was happening, and only give the
faulty result on those occasions. I’ve never heard of anyone running
production cryptography on an emulated CPU, since it would be too slow,
and virtualization technologies like Xen, KVM, and QEMU all
pass-through CPU instructions directly to hardware (for speed reasons)
when the virtualized guest matches the hardware architecture of the
host.

The point, however, is that proper description of the dangers of a
“security vulnerability” requires more than a single bit
field. Some security vulnerabilities are much worse than others. This
one is substantially closer to the “oh, that’s cute” end of
the spectrum, not the “ZOMG, everyone’s going to experience
identity theft tomorrow” side.

⁰Many casual
users don’t realize that cryptography — the stuff that secures your
networked data from unwanted viewers — isn’t about math problems
that are unsolvable. In fact, it’s often based on math problems that are
trivially solvable, but take a very long time to solve. This is why
algorithmic complexity questions are central to the question of
cryptographic security.

¹ I’m
oversimplifying a bit here. A key factor in the paper appears to be the
linear time algorithm used to compute cryptographic digital signatures,
and the fact that the signatures aren’t verified for integrity before
being deployed. I suspect, though, that just about any RSA system is
going to do this. (Although I do usually test the integrity of my GnuPG
signatures before sending them out, I do this as a user by hand).

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2010/03/05/crypto-fear.html

Boy, do I hate it when a
FLOSS
project is given a hard time unfairly. I was this morning greeted
with news
from many
places that OpenSSL, one of the
most common FLOSS software libraries used for cryptography, was
somehow severely vulnerable.

I had a hunch what was going on. I quickly downloaded
a copy
of the academic paper that was cited as the sole source for the
story and read it. As I feared, OpenSSL was getting some bad press
unfairly. One must really read this academic computer science article
in the context it was written; most commenting about this paper
probably did not.

First of all, I don’t claim to be an expert on cryptography, and I
think my knowledge level to opine on this subject remains limited to a
little blog post like this and nothing more. Between college and
graduate school, I worked as a system administrator focusing on network
security. While a computer science graduate student, I did take two
cryptography courses, two theory of computation courses, and one class
on complexity theory⁰. So, when
compared to the general population I probably am an expert, but compared to
people who actually work in cryptography regularly, I’m clearly a
novice. However, I suspect many who have hitherto opined about this
academic article to declare this severe vulnerability have even
less knowledge than I do on the subject.

This article, of course, wasn’t written for novices like me, and
certainly not for the general public nor the technology press. It was
written by and for professional researchers who spend much time each
week reading dozens of these academic papers, a task I haven’t done
since graduate school. Indeed, the paper is written in a style I know
well; my “welcome to CS graduate school” seminar in 1997
covered the format well.

The first thing you have to note about such papers is that informed
readers generally ignore the parts that a newbie is most likely focus
on: the Abstract, Introduction and Conclusion sections. These sections
are promotional materials; they are equivalent to a sales brochure
selling you on how important and groundbreaking the research is. Some
research is groundbreaking, of course, but most is an incremental step
forward toward understanding some theoretical concept, or some report
about an isolated but interesting experimental finding.

Unfortunately, these promotional parts of the paper are the sections
that focus on the negative implications for OpenSSL. In the rest of the
paper, OpenSSL is merely the software component of the experiment
equipment. They likely could have used GNU TLS or any other
implementation of RSA taken from a book on
cryptography¹. But this fact
is not even the primary reason that this article isn’t really that big
of a deal for daily use of cryptography.

The experiment described in the paper is very difficult to reproduce.
You have to cause very subtle faults in computation at specific times.
As I understand it, they had to assemble a specialized hardware copy of
a SPARC-based GNU/Linux environment to accomplish the experiment.

Next, the data generated during the run of the software on the
specially-constructed faulty hardware must be collected and operated
upon by a parallel processing computing environment over the course of
many hours. If it turns out all the needed data was gathered, the
output of this whole process is the private RSA key.

The details of the fault generation process deserve special mention.
Very specific faults have to occur, and they can’t occur such that any
other parts of the computation (such as, say, the normal running of the
operating system) are interrupted or corrupted. This is somewhat
straightforward to get done in a lab environment, but accomplishing it
in a production situation would be impractical and improbable. It would
also usually require physical access to the hardware holding the private
key. Such physical access would, of course, probably give you the
private key anyway by simply copying it off the hard drive or out of
RAM!

This is interesting research, and it does suggest some changes that
might be useful. For example, if it doesn’t slow a system down too
much, the integrity of RSA signatures should be verified, on a closely
controlled proxy unit with a separate CPU, before sending out to a wider
audience. But even that would be a process only for the most paranoid.
If faults are occurring on production hardware enough to generate the
bad computations this cracking process relies on, likely something else
will go wrong on the hardware too and it will be declared generally
unusable for production before an interloper could gather enough data to
crack the key. Thus, another useful change to make based on this
finding is to disable and discard RSA keys that were in use on
production hardware that went faulty.

Finally, I think this article does completely convince me that I would
never want to run any RSA computations on a system where the CPU was
emulated. Causing faults in an emulated CPU would only require changes
to the emulation software, and could be done with careful precision to
detect when an RSA-related computation was happening, and only give the
faulty result on those occasions. I’ve never heard of anyone running
production cryptography on an emulated CPU, since it would be too slow,
and virtualization technologies like Xen, KVM, and QEMU all
pass-through CPU instructions directly to hardware (for speed reasons)
when the virtualized guest matches the hardware architecture of the
host.

The point, however, is that proper description of the dangers of a
“security vulnerability” requires more than a single bit
field. Some security vulnerabilities are much worse than others. This
one is substantially closer to the “oh, that’s cute” end of
the spectrum, not the “ZOMG, everyone’s going to experience
identity theft tomorrow” side.

⁰Many casual
users don’t realize that cryptography — the stuff that secures your
networked data from unwanted viewers — isn’t about math problems
that are unsolvable. In fact, it’s often based on math problems that are
trivially solvable, but take a very long time to solve. This is why
algorithmic complexity questions are central to the question of
cryptographic security.

¹ I’m
oversimplifying a bit here. A key factor in the paper appears to be the
linear time algorithm used to compute cryptographic digital signatures,
and the fact that the signatures aren’t verified for integrity before
being deployed. I suspect, though, that just about any RSA system is
going to do this. (Although I do usually test the integrity of my GnuPG
signatures before sending them out, I do this as a user by hand).

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2010/03/05/crypto-fear.html

Boy, do I hate it when a
FLOSS
project is given a hard time unfairly. I was this morning greeted
with news
from many
places that OpenSSL, one of the
most common FLOSS software libraries used for cryptography, was
somehow severely vulnerable.

I had a hunch what was going on. I quickly downloaded
a copy
of the academic paper that was cited as the sole source for the
story and read it. As I feared, OpenSSL was getting some bad press
unfairly. One must really read this academic computer science article
in the context it was written; most commenting about this paper
probably did not.

First of all, I don’t claim to be an expert on cryptography, and I
think my knowledge level to opine on this subject remains limited to a
little blog post like this and nothing more. Between college and
graduate school, I worked as a system administrator focusing on network
security. While a computer science graduate student, I did take two
cryptography courses, two theory of computation courses, and one class
on complexity theory⁰. So, when
compared to the general population I probably am an expert, but compared to
people who actually work in cryptography regularly, I’m clearly a
novice. However, I suspect many who have hitherto opined about this
academic article to declare this severe vulnerability have even
less knowledge than I do on the subject.

This article, of course, wasn’t written for novices like me, and
certainly not for the general public nor the technology press. It was
written by and for professional researchers who spend much time each
week reading dozens of these academic papers, a task I haven’t done
since graduate school. Indeed, the paper is written in a style I know
well; my “welcome to CS graduate school” seminar in 1997
covered the format well.

The first thing you have to note about such papers is that informed
readers generally ignore the parts that a newbie is most likely focus
on: the Abstract, Introduction and Conclusion sections. These sections
are promotional materials; they are equivalent to a sales brochure
selling you on how important and groundbreaking the research is. Some
research is groundbreaking, of course, but most is an incremental step
forward toward understanding some theoretical concept, or some report
about an isolated but interesting experimental finding.

Unfortunately, these promotional parts of the paper are the sections
that focus on the negative implications for OpenSSL. In the rest of the
paper, OpenSSL is merely the software component of the experiment
equipment. They likely could have used GNU TLS or any other
implementation of RSA taken from a book on
cryptography¹. But this fact
is not even the primary reason that this article isn’t really that big
of a deal for daily use of cryptography.

The experiment described in the paper is very difficult to reproduce.
You have to cause very subtle faults in computation at specific times.
As I understand it, they had to assemble a specialized hardware copy of
a SPARC-based GNU/Linux environment to accomplish the experiment.

Next, the data generated during the run of the software on the
specially-constructed faulty hardware must be collected and operated
upon by a parallel processing computing environment over the course of
many hours. If it turns out all the needed data was gathered, the
output of this whole process is the private RSA key.

The details of the fault generation process deserve special mention.
Very specific faults have to occur, and they can’t occur such that any
other parts of the computation (such as, say, the normal running of the
operating system) are interrupted or corrupted. This is somewhat
straightforward to get done in a lab environment, but accomplishing it
in a production situation would be impractical and improbable. It would
also usually require physical access to the hardware holding the private
key. Such physical access would, of course, probably give you the
private key anyway by simply copying it off the hard drive or out of
RAM!

This is interesting research, and it does suggest some changes that
might be useful. For example, if it doesn’t slow a system down too
much, the integrity of RSA signatures should be verified, on a closely
controlled proxy unit with a separate CPU, before sending out to a wider
audience. But even that would be a process only for the most paranoid.
If faults are occurring on production hardware enough to generate the
bad computations this cracking process relies on, likely something else
will go wrong on the hardware too and it will be declared generally
unusable for production before an interloper could gather enough data to
crack the key. Thus, another useful change to make based on this
finding is to disable and discard RSA keys that were in use on
production hardware that went faulty.

Finally, I think this article does completely convince me that I would
never want to run any RSA computations on a system where the CPU was
emulated. Causing faults in an emulated CPU would only require changes
to the emulation software, and could be done with careful precision to
detect when an RSA-related computation was happening, and only give the
faulty result on those occasions. I’ve never heard of anyone running
production cryptography on an emulated CPU, since it would be too slow,
and virtualization technologies like Xen, KVM, and QEMU all
pass-through CPU instructions directly to hardware (for speed reasons)
when the virtualized guest matches the hardware architecture of the
host.

The point, however, is that proper description of the dangers of a
“security vulnerability” requires more than a single bit
field. Some security vulnerabilities are much worse than others. This
one is substantially closer to the “oh, that’s cute” end of
the spectrum, not the “ZOMG, everyone’s going to experience
identity theft tomorrow” side.

⁰Many casual
users don’t realize that cryptography — the stuff that secures your
networked data from unwanted viewers — isn’t about math problems
that are unsolvable. In fact, it’s often based on math problems that are
trivially solvable, but take a very long time to solve. This is why
algorithmic complexity questions are central to the question of
cryptographic security.

¹ I’m
oversimplifying a bit here. A key factor in the paper appears to be the
linear time algorithm used to compute cryptographic digital signatures,
and the fact that the signatures aren’t verified for integrity before
being deployed. I suspect, though, that just about any RSA system is
going to do this. (Although I do usually test the integrity of my GnuPG
signatures before sending them out, I do this as a user by hand).

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2010/03/05/crypto-fear.html

Boy, do I hate it when a
FLOSS
project is given a hard time unfairly. I was this morning greeted
with news
from many
places that OpenSSL, one of the
most common FLOSS software libraries used for cryptography, was
somehow severely vulnerable.

I had a hunch what was going on. I quickly downloaded
a copy
of the academic paper that was cited as the sole source for the
story and read it. As I feared, OpenSSL was getting some bad press
unfairly. One must really read this academic computer science article
in the context it was written; most commenting about this paper
probably did not.

First of all, I don’t claim to be an expert on cryptography, and I
think my knowledge level to opine on this subject remains limited to a
little blog post like this and nothing more. Between college and
graduate school, I worked as a system administrator focusing on network
security. While a computer science graduate student, I did take two
cryptography courses, two theory of computation courses, and one class
on complexity theory⁰. So, when
compared to the general population I probably am an expert, but compared to
people who actually work in cryptography regularly, I’m clearly a
novice. However, I suspect many who have hitherto opined about this
academic article to declare this severe vulnerability have even
less knowledge than I do on the subject.

This article, of course, wasn’t written for novices like me, and
certainly not for the general public nor the technology press. It was
written by and for professional researchers who spend much time each
week reading dozens of these academic papers, a task I haven’t done
since graduate school. Indeed, the paper is written in a style I know
well; my “welcome to CS graduate school” seminar in 1997
covered the format well.

The first thing you have to note about such papers is that informed
readers generally ignore the parts that a newbie is most likely focus
on: the Abstract, Introduction and Conclusion sections. These sections
are promotional materials; they are equivalent to a sales brochure
selling you on how important and groundbreaking the research is. Some
research is groundbreaking, of course, but most is an incremental step
forward toward understanding some theoretical concept, or some report
about an isolated but interesting experimental finding.

Unfortunately, these promotional parts of the paper are the sections
that focus on the negative implications for OpenSSL. In the rest of the
paper, OpenSSL is merely the software component of the experiment
equipment. They likely could have used GNU TLS or any other
implementation of RSA taken from a book on
cryptography¹. But this fact
is not even the primary reason that this article isn’t really that big
of a deal for daily use of cryptography.

The experiment described in the paper is very difficult to reproduce.
You have to cause very subtle faults in computation at specific times.
As I understand it, they had to assemble a specialized hardware copy of
a SPARC-based GNU/Linux environment to accomplish the experiment.

Next, the data generated during the run of the software on the
specially-constructed faulty hardware must be collected and operated
upon by a parallel processing computing environment over the course of
many hours. If it turns out all the needed data was gathered, the
output of this whole process is the private RSA key.

The details of the fault generation process deserve special mention.
Very specific faults have to occur, and they can’t occur such that any
other parts of the computation (such as, say, the normal running of the
operating system) are interrupted or corrupted. This is somewhat
straightforward to get done in a lab environment, but accomplishing it
in a production situation would be impractical and improbable. It would
also usually require physical access to the hardware holding the private
key. Such physical access would, of course, probably give you the
private key anyway by simply copying it off the hard drive or out of
RAM!

This is interesting research, and it does suggest some changes that
might be useful. For example, if it doesn’t slow a system down too
much, the integrity of RSA signatures should be verified, on a closely
controlled proxy unit with a separate CPU, before sending out to a wider
audience. But even that would be a process only for the most paranoid.
If faults are occurring on production hardware enough to generate the
bad computations this cracking process relies on, likely something else
will go wrong on the hardware too and it will be declared generally
unusable for production before an interloper could gather enough data to
crack the key. Thus, another useful change to make based on this
finding is to disable and discard RSA keys that were in use on
production hardware that went faulty.

Finally, I think this article does completely convince me that I would
never want to run any RSA computations on a system where the CPU was
emulated. Causing faults in an emulated CPU would only require changes
to the emulation software, and could be done with careful precision to
detect when an RSA-related computation was happening, and only give the
faulty result on those occasions. I’ve never heard of anyone running
production cryptography on an emulated CPU, since it would be too slow,
and virtualization technologies like Xen, KVM, and QEMU all
pass-through CPU instructions directly to hardware (for speed reasons)
when the virtualized guest matches the hardware architecture of the
host.

The point, however, is that proper description of the dangers of a
“security vulnerability” requires more than a single bit
field. Some security vulnerabilities are much worse than others. This
one is substantially closer to the “oh, that’s cute” end of
the spectrum, not the “ZOMG, everyone’s going to experience
identity theft tomorrow” side.

⁰Many casual
users don’t realize that cryptography — the stuff that secures your
networked data from unwanted viewers — isn’t about math problems
that are unsolvable. In fact, it’s often based on math problems that are
trivially solvable, but take a very long time to solve. This is why
algorithmic complexity questions are central to the question of
cryptographic security.

¹ I’m
oversimplifying a bit here. A key factor in the paper appears to be the
linear time algorithm used to compute cryptographic digital signatures,
and the fact that the signatures aren’t verified for integrity before
being deployed. I suspect, though, that just about any RSA system is
going to do this. (Although I do usually test the integrity of my GnuPG
signatures before sending them out, I do this as a user by hand).

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2010/03/05/crypto-fear.html

Boy, do I hate it when a
FLOSS
project is given a hard time unfairly. I was this morning greeted
with news
from many
places that OpenSSL, one of the
most common FLOSS software libraries used for cryptography, was
somehow severely vulnerable.

I had a hunch what was going on. I quickly downloaded
a copy
of the academic paper that was cited as the sole source for the
story and read it. As I feared, OpenSSL was getting some bad press
unfairly. One must really read this academic computer science article
in the context it was written; most commenting about this paper
probably did not.

First of all, I don’t claim to be an expert on cryptography, and I
think my knowledge level to opine on this subject remains limited to a
little blog post like this and nothing more. Between college and
graduate school, I worked as a system administrator focusing on network
security. While a computer science graduate student, I did take two
cryptography courses, two theory of computation courses, and one class
on complexity theory⁰. So, when
compared to the general population I probably am an expert, but compared to
people who actually work in cryptography regularly, I’m clearly a
novice. However, I suspect many who have hitherto opined about this
academic article to declare this severe vulnerability have even
less knowledge than I do on the subject.

This article, of course, wasn’t written for novices like me, and
certainly not for the general public nor the technology press. It was
written by and for professional researchers who spend much time each
week reading dozens of these academic papers, a task I haven’t done
since graduate school. Indeed, the paper is written in a style I know
well; my “welcome to CS graduate school” seminar in 1997
covered the format well.

The first thing you have to note about such papers is that informed
readers generally ignore the parts that a newbie is most likely focus
on: the Abstract, Introduction and Conclusion sections. These sections
are promotional materials; they are equivalent to a sales brochure
selling you on how important and groundbreaking the research is. Some
research is groundbreaking, of course, but most is an incremental step
forward toward understanding some theoretical concept, or some report
about an isolated but interesting experimental finding.

Unfortunately, these promotional parts of the paper are the sections
that focus on the negative implications for OpenSSL. In the rest of the
paper, OpenSSL is merely the software component of the experiment
equipment. They likely could have used GNU TLS or any other
implementation of RSA taken from a book on
cryptography¹. But this fact
is not even the primary reason that this article isn’t really that big
of a deal for daily use of cryptography.

The experiment described in the paper is very difficult to reproduce.
You have to cause very subtle faults in computation at specific times.
As I understand it, they had to assemble a specialized hardware copy of
a SPARC-based GNU/Linux environment to accomplish the experiment.

Next, the data generated during the run of the software on the
specially-constructed faulty hardware must be collected and operated
upon by a parallel processing computing environment over the course of
many hours. If it turns out all the needed data was gathered, the
output of this whole process is the private RSA key.

The details of the fault generation process deserve special mention.
Very specific faults have to occur, and they can’t occur such that any
other parts of the computation (such as, say, the normal running of the
operating system) are interrupted or corrupted. This is somewhat
straightforward to get done in a lab environment, but accomplishing it
in a production situation would be impractical and improbable. It would
also usually require physical access to the hardware holding the private
key. Such physical access would, of course, probably give you the
private key anyway by simply copying it off the hard drive or out of
RAM!

This is interesting research, and it does suggest some changes that
might be useful. For example, if it doesn’t slow a system down too
much, the integrity of RSA signatures should be verified, on a closely
controlled proxy unit with a separate CPU, before sending out to a wider
audience. But even that would be a process only for the most paranoid.
If faults are occurring on production hardware enough to generate the
bad computations this cracking process relies on, likely something else
will go wrong on the hardware too and it will be declared generally
unusable for production before an interloper could gather enough data to
crack the key. Thus, another useful change to make based on this
finding is to disable and discard RSA keys that were in use on
production hardware that went faulty.

Finally, I think this article does completely convince me that I would
never want to run any RSA computations on a system where the CPU was
emulated. Causing faults in an emulated CPU would only require changes
to the emulation software, and could be done with careful precision to
detect when an RSA-related computation was happening, and only give the
faulty result on those occasions. I’ve never heard of anyone running
production cryptography on an emulated CPU, since it would be too slow,
and virtualization technologies like Xen, KVM, and QEMU all
pass-through CPU instructions directly to hardware (for speed reasons)
when the virtualized guest matches the hardware architecture of the
host.

The point, however, is that proper description of the dangers of a
“security vulnerability” requires more than a single bit
field. Some security vulnerabilities are much worse than others. This
one is substantially closer to the “oh, that’s cute” end of
the spectrum, not the “ZOMG, everyone’s going to experience
identity theft tomorrow” side.

⁰Many casual
users don’t realize that cryptography — the stuff that secures your
networked data from unwanted viewers — isn’t about math problems
that are unsolvable. In fact, it’s often based on math problems that are
trivially solvable, but take a very long time to solve. This is why
algorithmic complexity questions are central to the question of
cryptographic security.

¹ I’m
oversimplifying a bit here. A key factor in the paper appears to be the
linear time algorithm used to compute cryptographic digital signatures,
and the fact that the signatures aren’t verified for integrity before
being deployed. I suspect, though, that just about any RSA system is
going to do this. (Although I do usually test the integrity of my GnuPG
signatures before sending them out, I do this as a user by hand).

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2010/03/05/crypto-fear.html

Boy, do I hate it when a
FLOSS
project is given a hard time unfairly. I was this morning greeted
with news
from many
places that OpenSSL, one of the
most common FLOSS software libraries used for cryptography, was
somehow severely vulnerable.

I had a hunch what was going on. I quickly downloaded
a copy
of the academic paper that was cited as the sole source for the
story and read it. As I feared, OpenSSL was getting some bad press
unfairly. One must really read this academic computer science article
in the context it was written; most commenting about this paper
probably did not.

First of all, I don’t claim to be an expert on cryptography, and I
think my knowledge level to opine on this subject remains limited to a
little blog post like this and nothing more. Between college and
graduate school, I worked as a system administrator focusing on network
security. While a computer science graduate student, I did take two
cryptography courses, two theory of computation courses, and one class
on complexity theory⁰. So, when
compared to the general population I probably am an expert, but compared to
people who actually work in cryptography regularly, I’m clearly a
novice. However, I suspect many who have hitherto opined about this
academic article to declare this severe vulnerability have even
less knowledge than I do on the subject.

This article, of course, wasn’t written for novices like me, and
certainly not for the general public nor the technology press. It was
written by and for professional researchers who spend much time each
week reading dozens of these academic papers, a task I haven’t done
since graduate school. Indeed, the paper is written in a style I know
well; my “welcome to CS graduate school” seminar in 1997
covered the format well.

The first thing you have to note about such papers is that informed
readers generally ignore the parts that a newbie is most likely focus
on: the Abstract, Introduction and Conclusion sections. These sections
are promotional materials; they are equivalent to a sales brochure
selling you on how important and groundbreaking the research is. Some
research is groundbreaking, of course, but most is an incremental step
forward toward understanding some theoretical concept, or some report
about an isolated but interesting experimental finding.

Unfortunately, these promotional parts of the paper are the sections
that focus on the negative implications for OpenSSL. In the rest of the
paper, OpenSSL is merely the software component of the experiment
equipment. They likely could have used GNU TLS or any other
implementation of RSA taken from a book on
cryptography¹. But this fact
is not even the primary reason that this article isn’t really that big
of a deal for daily use of cryptography.

The experiment described in the paper is very difficult to reproduce.
You have to cause very subtle faults in computation at specific times.
As I understand it, they had to assemble a specialized hardware copy of
a SPARC-based GNU/Linux environment to accomplish the experiment.

Next, the data generated during the run of the software on the
specially-constructed faulty hardware must be collected and operated
upon by a parallel processing computing environment over the course of
many hours. If it turns out all the needed data was gathered, the
output of this whole process is the private RSA key.

The details of the fault generation process deserve special mention.
Very specific faults have to occur, and they can’t occur such that any
other parts of the computation (such as, say, the normal running of the
operating system) are interrupted or corrupted. This is somewhat
straightforward to get done in a lab environment, but accomplishing it
in a production situation would be impractical and improbable. It would
also usually require physical access to the hardware holding the private
key. Such physical access would, of course, probably give you the
private key anyway by simply copying it off the hard drive or out of
RAM!

This is interesting research, and it does suggest some changes that
might be useful. For example, if it doesn’t slow a system down too
much, the integrity of RSA signatures should be verified, on a closely
controlled proxy unit with a separate CPU, before sending out to a wider
audience. But even that would be a process only for the most paranoid.
If faults are occurring on production hardware enough to generate the
bad computations this cracking process relies on, likely something else
will go wrong on the hardware too and it will be declared generally
unusable for production before an interloper could gather enough data to
crack the key. Thus, another useful change to make based on this
finding is to disable and discard RSA keys that were in use on
production hardware that went faulty.

Finally, I think this article does completely convince me that I would
never want to run any RSA computations on a system where the CPU was
emulated. Causing faults in an emulated CPU would only require changes
to the emulation software, and could be done with careful precision to
detect when an RSA-related computation was happening, and only give the
faulty result on those occasions. I’ve never heard of anyone running
production cryptography on an emulated CPU, since it would be too slow,
and virtualization technologies like Xen, KVM, and QEMU all
pass-through CPU instructions directly to hardware (for speed reasons)
when the virtualized guest matches the hardware architecture of the
host.

The point, however, is that proper description of the dangers of a
“security vulnerability” requires more than a single bit
field. Some security vulnerabilities are much worse than others. This
one is substantially closer to the “oh, that’s cute” end of
the spectrum, not the “ZOMG, everyone’s going to experience
identity theft tomorrow” side.

⁰Many casual
users don’t realize that cryptography — the stuff that secures your
networked data from unwanted viewers — isn’t about math problems
that are unsolvable. In fact, it’s often based on math problems that are
trivially solvable, but take a very long time to solve. This is why
algorithmic complexity questions are central to the question of
cryptographic security.

¹ I’m
oversimplifying a bit here. A key factor in the paper appears to be the
linear time algorithm used to compute cryptographic digital signatures,
and the fact that the signatures aren’t verified for integrity before
being deployed. I suspect, though, that just about any RSA system is
going to do this. (Although I do usually test the integrity of my GnuPG
signatures before sending them out, I do this as a user by hand).

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2010/03/05/crypto-fear.html

Boy, do I hate it when a
FLOSS
project is given a hard time unfairly. I was this morning greeted
with news
from many
places that OpenSSL, one of the
most common FLOSS software libraries used for cryptography, was
somehow severely vulnerable.

I had a hunch what was going on. I quickly downloaded
a copy
of the academic paper that was cited as the sole source for the
story and read it. As I feared, OpenSSL was getting some bad press
unfairly. One must really read this academic computer science article
in the context it was written; most commenting about this paper
probably did not.

First of all, I don’t claim to be an expert on cryptography, and I
think my knowledge level to opine on this subject remains limited to a
little blog post like this and nothing more. Between college and
graduate school, I worked as a system administrator focusing on network
security. While a computer science graduate student, I did take two
cryptography courses, two theory of computation courses, and one class
on complexity theory⁰. So, when
compared to the general population I probably am an expert, but compared to
people who actually work in cryptography regularly, I’m clearly a
novice. However, I suspect many who have hitherto opined about this
academic article to declare this severe vulnerability have even
less knowledge than I do on the subject.

This article, of course, wasn’t written for novices like me, and
certainly not for the general public nor the technology press. It was
written by and for professional researchers who spend much time each
week reading dozens of these academic papers, a task I haven’t done
since graduate school. Indeed, the paper is written in a style I know
well; my “welcome to CS graduate school” seminar in 1997
covered the format well.

The first thing you have to note about such papers is that informed
readers generally ignore the parts that a newbie is most likely focus
on: the Abstract, Introduction and Conclusion sections. These sections
are promotional materials; they are equivalent to a sales brochure
selling you on how important and groundbreaking the research is. Some
research is groundbreaking, of course, but most is an incremental step
forward toward understanding some theoretical concept, or some report
about an isolated but interesting experimental finding.

Unfortunately, these promotional parts of the paper are the sections
that focus on the negative implications for OpenSSL. In the rest of the
paper, OpenSSL is merely the software component of the experiment
equipment. They likely could have used GNU TLS or any other
implementation of RSA taken from a book on
cryptography¹. But this fact
is not even the primary reason that this article isn’t really that big
of a deal for daily use of cryptography.

The experiment described in the paper is very difficult to reproduce.
You have to cause very subtle faults in computation at specific times.
As I understand it, they had to assemble a specialized hardware copy of
a SPARC-based GNU/Linux environment to accomplish the experiment.

Next, the data generated during the run of the software on the
specially-constructed faulty hardware must be collected and operated
upon by a parallel processing computing environment over the course of
many hours. If it turns out all the needed data was gathered, the
output of this whole process is the private RSA key.

The details of the fault generation process deserve special mention.
Very specific faults have to occur, and they can’t occur such that any
other parts of the computation (such as, say, the normal running of the
operating system) are interrupted or corrupted. This is somewhat
straightforward to get done in a lab environment, but accomplishing it
in a production situation would be impractical and improbable. It would
also usually require physical access to the hardware holding the private
key. Such physical access would, of course, probably give you the
private key anyway by simply copying it off the hard drive or out of
RAM!

This is interesting research, and it does suggest some changes that
might be useful. For example, if it doesn’t slow a system down too
much, the integrity of RSA signatures should be verified, on a closely
controlled proxy unit with a separate CPU, before sending out to a wider
audience. But even that would be a process only for the most paranoid.
If faults are occurring on production hardware enough to generate the
bad computations this cracking process relies on, likely something else
will go wrong on the hardware too and it will be declared generally
unusable for production before an interloper could gather enough data to
crack the key. Thus, another useful change to make based on this
finding is to disable and discard RSA keys that were in use on
production hardware that went faulty.

Finally, I think this article does completely convince me that I would
never want to run any RSA computations on a system where the CPU was
emulated. Causing faults in an emulated CPU would only require changes
to the emulation software, and could be done with careful precision to
detect when an RSA-related computation was happening, and only give the
faulty result on those occasions. I’ve never heard of anyone running
production cryptography on an emulated CPU, since it would be too slow,
and virtualization technologies like Xen, KVM, and QEMU all
pass-through CPU instructions directly to hardware (for speed reasons)
when the virtualized guest matches the hardware architecture of the
host.

The point, however, is that proper description of the dangers of a
“security vulnerability” requires more than a single bit
field. Some security vulnerabilities are much worse than others. This
one is substantially closer to the “oh, that’s cute” end of
the spectrum, not the “ZOMG, everyone’s going to experience
identity theft tomorrow” side.

⁰Many casual
users don’t realize that cryptography — the stuff that secures your
networked data from unwanted viewers — isn’t about math problems
that are unsolvable. In fact, it’s often based on math problems that are
trivially solvable, but take a very long time to solve. This is why
algorithmic complexity questions are central to the question of
cryptographic security.

¹ I’m
oversimplifying a bit here. A key factor in the paper appears to be the
linear time algorithm used to compute cryptographic digital signatures,
and the fact that the signatures aren’t verified for integrity before
being deployed. I suspect, though, that just about any RSA system is
going to do this. (Although I do usually test the integrity of my GnuPG
signatures before sending them out, I do this as a user by hand).

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2010/03/05/crypto-fear.html

Boy, do I hate it when a
FLOSS
project is given a hard time unfairly. I was this morning greeted
with news
from many
places that OpenSSL, one of the
most common FLOSS software libraries used for cryptography, was
somehow severely vulnerable.

I had a hunch what was going on. I quickly downloaded
a copy
of the academic paper that was cited as the sole source for the
story and read it. As I feared, OpenSSL was getting some bad press
unfairly. One must really read this academic computer science article
in the context it was written; most commenting about this paper
probably did not.

First of all, I don’t claim to be an expert on cryptography, and I
think my knowledge level to opine on this subject remains limited to a
little blog post like this and nothing more. Between college and
graduate school, I worked as a system administrator focusing on network
security. While a computer science graduate student, I did take two
cryptography courses, two theory of computation courses, and one class
on complexity theory⁰. So, when
compared to the general population I probably am an expert, but compared to
people who actually work in cryptography regularly, I’m clearly a
novice. However, I suspect many who have hitherto opined about this
academic article to declare this severe vulnerability have even
less knowledge than I do on the subject.

This article, of course, wasn’t written for novices like me, and
certainly not for the general public nor the technology press. It was
written by and for professional researchers who spend much time each
week reading dozens of these academic papers, a task I haven’t done
since graduate school. Indeed, the paper is written in a style I know
well; my “welcome to CS graduate school” seminar in 1997
covered the format well.

The first thing you have to note about such papers is that informed
readers generally ignore the parts that a newbie is most likely focus
on: the Abstract, Introduction and Conclusion sections. These sections
are promotional materials; they are equivalent to a sales brochure
selling you on how important and groundbreaking the research is. Some
research is groundbreaking, of course, but most is an incremental step
forward toward understanding some theoretical concept, or some report
about an isolated but interesting experimental finding.

Unfortunately, these promotional parts of the paper are the sections
that focus on the negative implications for OpenSSL. In the rest of the
paper, OpenSSL is merely the software component of the experiment
equipment. They likely could have used GNU TLS or any other
implementation of RSA taken from a book on
cryptography¹. But this fact
is not even the primary reason that this article isn’t really that big
of a deal for daily use of cryptography.

The experiment described in the paper is very difficult to reproduce.
You have to cause very subtle faults in computation at specific times.
As I understand it, they had to assemble a specialized hardware copy of
a SPARC-based GNU/Linux environment to accomplish the experiment.

Next, the data generated during the run of the software on the
specially-constructed faulty hardware must be collected and operated
upon by a parallel processing computing environment over the course of
many hours. If it turns out all the needed data was gathered, the
output of this whole process is the private RSA key.

The details of the fault generation process deserve special mention.
Very specific faults have to occur, and they can’t occur such that any
other parts of the computation (such as, say, the normal running of the
operating system) are interrupted or corrupted. This is somewhat
straightforward to get done in a lab environment, but accomplishing it
in a production situation would be impractical and improbable. It would
also usually require physical access to the hardware holding the private
key. Such physical access would, of course, probably give you the
private key anyway by simply copying it off the hard drive or out of
RAM!

This is interesting research, and it does suggest some changes that
might be useful. For example, if it doesn’t slow a system down too
much, the integrity of RSA signatures should be verified, on a closely
controlled proxy unit with a separate CPU, before sending out to a wider
audience. But even that would be a process only for the most paranoid.
If faults are occurring on production hardware enough to generate the
bad computations this cracking process relies on, likely something else
will go wrong on the hardware too and it will be declared generally
unusable for production before an interloper could gather enough data to
crack the key. Thus, another useful change to make based on this
finding is to disable and discard RSA keys that were in use on
production hardware that went faulty.

Finally, I think this article does completely convince me that I would
never want to run any RSA computations on a system where the CPU was
emulated. Causing faults in an emulated CPU would only require changes
to the emulation software, and could be done with careful precision to
detect when an RSA-related computation was happening, and only give the
faulty result on those occasions. I’ve never heard of anyone running
production cryptography on an emulated CPU, since it would be too slow,
and virtualization technologies like Xen, KVM, and QEMU all
pass-through CPU instructions directly to hardware (for speed reasons)
when the virtualized guest matches the hardware architecture of the
host.

The point, however, is that proper description of the dangers of a
“security vulnerability” requires more than a single bit
field. Some security vulnerabilities are much worse than others. This
one is substantially closer to the “oh, that’s cute” end of
the spectrum, not the “ZOMG, everyone’s going to experience
identity theft tomorrow” side.

⁰Many casual
users don’t realize that cryptography — the stuff that secures your
networked data from unwanted viewers — isn’t about math problems
that are unsolvable. In fact, it’s often based on math problems that are
trivially solvable, but take a very long time to solve. This is why
algorithmic complexity questions are central to the question of
cryptographic security.

¹ I’m
oversimplifying a bit here. A key factor in the paper appears to be the
linear time algorithm used to compute cryptographic digital signatures,
and the fact that the signatures aren’t verified for integrity before
being deployed. I suspect, though, that just about any RSA system is
going to do this. (Although I do usually test the integrity of my GnuPG
signatures before sending them out, I do this as a user by hand).

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2010/03/05/crypto-fear.html

Boy, do I hate it when a
FLOSS
project is given a hard time unfairly. I was this morning greeted
with news
from many
places that OpenSSL, one of the
most common FLOSS software libraries used for cryptography, was
somehow severely vulnerable.

I had a hunch what was going on. I quickly downloaded
a copy
of the academic paper that was cited as the sole source for the
story and read it. As I feared, OpenSSL was getting some bad press
unfairly. One must really read this academic computer science article
in the context it was written; most commenting about this paper
probably did not.

First of all, I don’t claim to be an expert on cryptography, and I
think my knowledge level to opine on this subject remains limited to a
little blog post like this and nothing more. Between college and
graduate school, I worked as a system administrator focusing on network
security. While a computer science graduate student, I did take two
cryptography courses, two theory of computation courses, and one class
on complexity theory⁰. So, when
compared to the general population I probably am an expert, but compared to
people who actually work in cryptography regularly, I’m clearly a
novice. However, I suspect many who have hitherto opined about this
academic article to declare this severe vulnerability have even
less knowledge than I do on the subject.

This article, of course, wasn’t written for novices like me, and
certainly not for the general public nor the technology press. It was
written by and for professional researchers who spend much time each
week reading dozens of these academic papers, a task I haven’t done
since graduate school. Indeed, the paper is written in a style I know
well; my “welcome to CS graduate school” seminar in 1997
covered the format well.

The first thing you have to note about such papers is that informed
readers generally ignore the parts that a newbie is most likely focus
on: the Abstract, Introduction and Conclusion sections. These sections
are promotional materials; they are equivalent to a sales brochure
selling you on how important and groundbreaking the research is. Some
research is groundbreaking, of course, but most is an incremental step
forward toward understanding some theoretical concept, or some report
about an isolated but interesting experimental finding.

Unfortunately, these promotional parts of the paper are the sections
that focus on the negative implications for OpenSSL. In the rest of the
paper, OpenSSL is merely the software component of the experiment
equipment. They likely could have used GNU TLS or any other
implementation of RSA taken from a book on
cryptography¹. But this fact
is not even the primary reason that this article isn’t really that big
of a deal for daily use of cryptography.

The experiment described in the paper is very difficult to reproduce.
You have to cause very subtle faults in computation at specific times.
As I understand it, they had to assemble a specialized hardware copy of
a SPARC-based GNU/Linux environment to accomplish the experiment.

Next, the data generated during the run of the software on the
specially-constructed faulty hardware must be collected and operated
upon by a parallel processing computing environment over the course of
many hours. If it turns out all the needed data was gathered, the
output of this whole process is the private RSA key.

The details of the fault generation process deserve special mention.
Very specific faults have to occur, and they can’t occur such that any
other parts of the computation (such as, say, the normal running of the
operating system) are interrupted or corrupted. This is somewhat
straightforward to get done in a lab environment, but accomplishing it
in a production situation would be impractical and improbable. It would
also usually require physical access to the hardware holding the private
key. Such physical access would, of course, probably give you the
private key anyway by simply copying it off the hard drive or out of
RAM!

This is interesting research, and it does suggest some changes that
might be useful. For example, if it doesn’t slow a system down too
much, the integrity of RSA signatures should be verified, on a closely
controlled proxy unit with a separate CPU, before sending out to a wider
audience. But even that would be a process only for the most paranoid.
If faults are occurring on production hardware enough to generate the
bad computations this cracking process relies on, likely something else
will go wrong on the hardware too and it will be declared generally
unusable for production before an interloper could gather enough data to
crack the key. Thus, another useful change to make based on this
finding is to disable and discard RSA keys that were in use on
production hardware that went faulty.

Finally, I think this article does completely convince me that I would
never want to run any RSA computations on a system where the CPU was
emulated. Causing faults in an emulated CPU would only require changes
to the emulation software, and could be done with careful precision to
detect when an RSA-related computation was happening, and only give the
faulty result on those occasions. I’ve never heard of anyone running
production cryptography on an emulated CPU, since it would be too slow,
and virtualization technologies like Xen, KVM, and QEMU all
pass-through CPU instructions directly to hardware (for speed reasons)
when the virtualized guest matches the hardware architecture of the
host.

The point, however, is that proper description of the dangers of a
“security vulnerability” requires more than a single bit
field. Some security vulnerabilities are much worse than others. This
one is substantially closer to the “oh, that’s cute” end of
the spectrum, not the “ZOMG, everyone’s going to experience
identity theft tomorrow” side.

⁰Many casual
users don’t realize that cryptography — the stuff that secures your
networked data from unwanted viewers — isn’t about math problems
that are unsolvable. In fact, it’s often based on math problems that are
trivially solvable, but take a very long time to solve. This is why
algorithmic complexity questions are central to the question of
cryptographic security.

¹ I’m
oversimplifying a bit here. A key factor in the paper appears to be the
linear time algorithm used to compute cryptographic digital signatures,
and the fact that the signatures aren’t verified for integrity before
being deployed. I suspect, though, that just about any RSA system is
going to do this. (Although I do usually test the integrity of my GnuPG
signatures before sending them out, I do this as a user by hand).

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2010/03/05/crypto-fear.html

Boy, do I hate it when a
FLOSS
project is given a hard time unfairly. I was this morning greeted
with news
from many
places that OpenSSL, one of the
most common FLOSS software libraries used for cryptography, was
somehow severely vulnerable.

I had a hunch what was going on. I quickly downloaded
a copy
of the academic paper that was cited as the sole source for the
story and read it. As I feared, OpenSSL was getting some bad press
unfairly. One must really read this academic computer science article
in the context it was written; most commenting about this paper
probably did not.

First of all, I don’t claim to be an expert on cryptography, and I
think my knowledge level to opine on this subject remains limited to a
little blog post like this and nothing more. Between college and
graduate school, I worked as a system administrator focusing on network
security. While a computer science graduate student, I did take two
cryptography courses, two theory of computation courses, and one class
on complexity theory⁰. So, when
compared to the general population I probably am an expert, but compared to
people who actually work in cryptography regularly, I’m clearly a
novice. However, I suspect many who have hitherto opined about this
academic article to declare this severe vulnerability have even
less knowledge than I do on the subject.

This article, of course, wasn’t written for novices like me, and
certainly not for the general public nor the technology press. It was
written by and for professional researchers who spend much time each
week reading dozens of these academic papers, a task I haven’t done
since graduate school. Indeed, the paper is written in a style I know
well; my “welcome to CS graduate school” seminar in 1997
covered the format well.

The first thing you have to note about such papers is that informed
readers generally ignore the parts that a newbie is most likely focus
on: the Abstract, Introduction and Conclusion sections. These sections
are promotional materials; they are equivalent to a sales brochure
selling you on how important and groundbreaking the research is. Some
research is groundbreaking, of course, but most is an incremental step
forward toward understanding some theoretical concept, or some report
about an isolated but interesting experimental finding.

Unfortunately, these promotional parts of the paper are the sections
that focus on the negative implications for OpenSSL. In the rest of the
paper, OpenSSL is merely the software component of the experiment
equipment. They likely could have used GNU TLS or any other
implementation of RSA taken from a book on
cryptography¹. But this fact
is not even the primary reason that this article isn’t really that big
of a deal for daily use of cryptography.

The experiment described in the paper is very difficult to reproduce.
You have to cause very subtle faults in computation at specific times.
As I understand it, they had to assemble a specialized hardware copy of
a SPARC-based GNU/Linux environment to accomplish the experiment.

Next, the data generated during the run of the software on the
specially-constructed faulty hardware must be collected and operated
upon by a parallel processing computing environment over the course of
many hours. If it turns out all the needed data was gathered, the
output of this whole process is the private RSA key.

The details of the fault generation process deserve special mention.
Very specific faults have to occur, and they can’t occur such that any
other parts of the computation (such as, say, the normal running of the
operating system) are interrupted or corrupted. This is somewhat
straightforward to get done in a lab environment, but accomplishing it
in a production situation would be impractical and improbable. It would
also usually require physical access to the hardware holding the private
key. Such physical access would, of course, probably give you the
private key anyway by simply copying it off the hard drive or out of
RAM!

This is interesting research, and it does suggest some changes that
might be useful. For example, if it doesn’t slow a system down too
much, the integrity of RSA signatures should be verified, on a closely
controlled proxy unit with a separate CPU, before sending out to a wider
audience. But even that would be a process only for the most paranoid.
If faults are occurring on production hardware enough to generate the
bad computations this cracking process relies on, likely something else
will go wrong on the hardware too and it will be declared generally
unusable for production before an interloper could gather enough data to
crack the key. Thus, another useful change to make based on this
finding is to disable and discard RSA keys that were in use on
production hardware that went faulty.

Finally, I think this article does completely convince me that I would
never want to run any RSA computations on a system where the CPU was
emulated. Causing faults in an emulated CPU would only require changes
to the emulation software, and could be done with careful precision to
detect when an RSA-related computation was happening, and only give the
faulty result on those occasions. I’ve never heard of anyone running
production cryptography on an emulated CPU, since it would be too slow,
and virtualization technologies like Xen, KVM, and QEMU all
pass-through CPU instructions directly to hardware (for speed reasons)
when the virtualized guest matches the hardware architecture of the
host.

The point, however, is that proper description of the dangers of a
“security vulnerability” requires more than a single bit
field. Some security vulnerabilities are much worse than others. This
one is substantially closer to the “oh, that’s cute” end of
the spectrum, not the “ZOMG, everyone’s going to experience
identity theft tomorrow” side.

⁰Many casual
users don’t realize that cryptography — the stuff that secures your
networked data from unwanted viewers — isn’t about math problems
that are unsolvable. In fact, it’s often based on math problems that are
trivially solvable, but take a very long time to solve. This is why
algorithmic complexity questions are central to the question of
cryptographic security.

¹ I’m
oversimplifying a bit here. A key factor in the paper appears to be the
linear time algorithm used to compute cryptographic digital signatures,
and the fact that the signatures aren’t verified for integrity before
being deployed. I suspect, though, that just about any RSA system is
going to do this. (Although I do usually test the integrity of my GnuPG
signatures before sending them out, I do this as a user by hand).

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2010/03/04/mobile.html

I started using GNU/Linux and Free Software in 1992. In those days,
while everything I needed for a working computer was generally available
in software freedom, there were many components and applications that
simply did not exist. For highly technical users who did not need many
peripherals, the Free Software community had reached a state of complete
software freedom. Yet, in 1992, everyone agreed there was still much work
to be done. Even today, we still strive for a desktop and server
operating system, with all relevant applications, that grants complete
software freedom.

Looked at broadly, mobile telephone systems are not all that different
from 1992-era GNU/Linux systems. The basics are currently available as
Free, Libre, and Open Source Software (FLOSS). If you need only the bare
minimum of functionality, you can, by picking the right phone hardware,
run an almost completely FLOSS operating system and application set. Yet,
we have so far to go. This post discusses the current penetration of
FLOSS in mobile devices and offers a path forward for free software
advocates.

A Brief History

The mobile telephone market has never functioned like the traditional
computer market. Historically, the mobile user made arrangements with some
network carrier through a long-term contract. That carrier
“gave” the user a phone or discounted it as a loss-leader. Under
that system, few people take their phone hardware choice all that
seriously. Perhaps users pay a bit more for a slightly better phone, but
generally they nearly always pick among the limited choices provided by
the given carrier.

Meanwhile, Research in Motion was the first to provide
corporate-slave-oriented email-enabled devices. Indeed, with the very
recent focus on consumer-oriented devices like the iPhone, most users
forget that Apple is by far not the preferred fruit for the smart phone
user. Today, most people using a “smart phone” are using one
given to them by their employer to chain them to their office email 24/7.

Apple, excellent at manipulating users into paying more for a product
merely because it is shiny, also convinced everyone that now a phone
should be paid for separately, and contracts should go even longer. The
“race to mediocrity” of the phone market has ended. Phones
need real features to stand out. Phones, in fact, aren’t phones
anymore. They are small mobile computers that can also make phone calls.

If these small computers had been introduced in 1992, I suppose I’d be
left writing the Mobile GNU Manifesto, calling for developers
to start from scratch writing operating systems for these new computers,
so that all users could have software freedom. Fortunately, we have
instead been given a head start. Unlike in 1992, not every company in the
market today is completely against releasing Free Software. Specifically,
two companies have seen some value in releasing (some parts of) phone
operating systems as Free Software: Nokia and Google. However, the two
companies have done this for radically different reasons.

The Current State of Mobile Software Freedom

For its part, Nokia likely benefited greatly from the traditional
carrier system. Most of their phones were provided relatively cheaply with
contracts. Their interest in software freedom was limited and perhaps even
non-existent. Nokia sold new hardware every time a phone contract was
renewed, and the carrier paid the difference between the loss-leader price
and Nokia’s wholesale cost. The software on the devices was simple and
mostly internally developed. What incentive did Nokia have to release
software in software freedom? (Nokia realized too late this was the wrong
position, but more on that later.)

In parallel, Nokia had chased another market that I’ve never fully
understood: the tablet PC. Not big enough to be a real computer, but too
large to be a phone, these devices have been an idea looking for a user
base. Regardless of my personal views on these systems, though, GNU/Linux
remains the ideal system for these devices, and Nokia saw that. Nokia
built the Debian-ish Maemo system as a
tablet system, with no phone. However, I can count on one hand all the
people I’ve met who bothered with these devices; I just don’t think a
phone-less small computer is going to ever become the rage, even if Apple
dumps billions into marketing the iPad. (Anyone remember the Newton?)

I cannot explain, nor do I even understand, why Nokia took so long to
use Maemo as a platform for a tablet-like telephone. But, a few months
ago, they finally released
one. This N900 is among only a
few available phones that make any strides toward a fully free software
phone platform. Yet,
the list of
proprietary components required for operation remains quite long. The
common joke is that you can’t even charge the battery on your N900 without
proprietary software.

While there are surely people inside Nokia who want more software
freedom on their devices, Nokia is fundamentally a hardware company
experimenting with software freedom in hopes that it will bolster hardware
sales. Convincing Nokia to shorten that proprietary list will prove
difficult, and the community based effort to replace that long list with
FLOSS (called Mer) faces many
challenges. (These challenges will likely increase with the recent Maemo
merger with Moblin to form MeeGo).

Fortunately, hardware companies are not the only entity interested in
phone operating systems. Google, ever-focused on routing human eyes to its
controlled advertising, realizes that even more eyes will be on mobile
computing platforms in the future. With this goal in mind, Google released
the Android/Linux system, now available on a variety of phones in varying
degrees of software freedom.

Google’s motives are completely different than Nokia’s. Technically,
Google has no hardware to sell. They do have a set of proprietary
applications that yield the “Google online experience” to
deliver Google’s advertising. From Google’s point of view, an
easy-to-adopt, licensing-unencumbered platform will broaden their
advertising market.

Thus, Android/Linux is a nearly fully non-copylefted phone operating
system platform where Linux is the only GPL licensed component essential
to Android’s operation. Ideally, Google wants to see Android adopted
broadly in both Free Software and mixed Free/proprietary deployments.
Google’s goals do not match that of the software freedom community, so in
some cases, a given Android/Linux device will give the user more software
freedom than the N900, but in many cases it will give much less.

The HTC
Dream is the only Android/Linux device I know of where a careful
examination of the necessary proprietary components have been
analyzed. Obviously, the “Google experience” applications are
proprietary. There also
are about
20 hardware interface libraries that do not have source code available
in a public repository. However, when lined up against the N900 with
Maemo, Android on the HTC Dream can be used as an operational mobile
telephone and 3G Internet device using only three proprietary components:
a proprietary GSM firmware, proprietary Wifi firmware, and two audio
interface libraries. Further proprietary components are needed if you
want a working accelerometer, camera, and video codecs as their hardware
interface libraries are all proprietary.

Based on this analysis, it appears that the HTC Dream currently gives
the most software freedom among Android/Linux deployments. It is unlikely
that Google wants anything besides their applications to be proprietary.
While Google has been unresponsive when asked why these hardware interface
libraries are proprietary, it is likely that HTC, the hardware maker with
whom Google contracted, insisted that these components remain proprietary,
and perhaps
fear patent
suits like the one filed this week are to blame here. Meanwhile,
while no detailed analysis of
the Nexus One is yet available,
it’s likely similar to the HTC Dream.

Other Android/Linux devices are now available, such as those from
Motorola and Samsung. There appears to have been no detailed analysis done
yet on the relative proprietary/freeness ratio of these Android
deployments. One can surmise that since these devices are from
traditionally proprietary hardware makers, it is unlikely that these
platforms are freer than those available from Google, whose maximal
interest in a freely available operating system is clear and in contrast
to the traditional desires of hardware makers.

Whether the software is from a hardware-maker desperately trying a new
hardware sales strategy, or an advertising salesman who wants some
influence over an operating system choice to improve ad delivery, the
software freedom community cannot assume that the stewards of these
codebases have the interests of the user community at heart. Indeed, the
interests between these disparate groups will only occasionally be
aligned. Community-oriented forks, as has begun in the Maemo community
with Mer, must also begin in the Android/Linux space too. We are slowly
trying with
the Replicant
project, founded by myself and my colleague Aaron Williamson.

A healthy community-oriented phone operating system project will
ultimately be an essential component to software freedom on these devices.
For example, consider the fate of the Mer project now that Nokia has
announced the merger of Maemo with Moblin. Mer does seek to cherry-pick
from various small device systems, but its focus was to create a freer
Maemo that worked on more devices. Mer now must choose between following
the Maemo in the merge with Moblin, or becoming a true fork. Ideally, the
right outcome for software freedom is a community-led effort, but there
may not be enough community interest, time and commitment to shepherd a
fork while Intel and Nokia push forward on a corporate-controlled
codebase. Further, Moblin will likely push the MeeGo project toward more
of a tablet-PC operating system than a smart phone.

A community-oriented Android/Linux fork has more hope. Google has
little to lose by encouraging and even assisting with such forks; such
effort would actually be wholly consistent with Google’s goals for wider
adoption of platforms that allow deployment of Google’s proprietary
applications. I expect that operating system
software-freedom-motivated efforts will be met with more support from
Google than from Nokia and/or Intel.

However, any operating system, even a mobile device one, needs many
applications to be useful. Google experience applications for
Android/Linux are merely the beginning of the plethora of proprietary
applications that will ultimately be available for MeeGo and Android/Linux
platforms. For FLOSS developers who don’t have a talent for low-level
device libraries and operating system software, these applications
represent a straightforward contribution towards mobile software
freedom. (Obviously, though, if one does have talent for low-level
programming, replacing the proprietary .so’s on Android/Linux would be the
optimal contribution.)

Indeed, on this point, we can take a page from Free Software history.
From the early 1990s onward, fully free GNU/Linux systems succeeded as
viable desktop and server systems because disparate groups of developers
focused simultaneously on both operating systems and application software.
We need that simultaneous diversity of improvement to actually compete
with the fully proprietary alternatives, and to ensure that the
“mostly FLOSS” systems of today are not the “barely
FLOSS” systems of tomorrow.

Careful readers have likely noticed that I have ignored Nokia’s other
release, the Symbian> codebase. Every time I write or speak about the
issues of software freedom in mobile devices, I’m chastised for leaving it
out of the story. My answer is always simple: when a FLOSS version of
Symbian can be compiled from source code, using a FLOSS compiler or SDK,
and that binary can be installed onto an actual working mobile phone
device, then (and only then) will I believe that the Symbian source
release has value beyond historical interest. We have to get honest as a
community about the future of Symbian: it’s a ten-year-old proprietary
codebase designed for devices of that era that doesn’t bootstrap with any
compilers our community uses regularly. Unless there’s a radical change
to these facts, the code belongs in a museum, not running on a phone.

Also, lest my own community of hard-core FLOSS advocates flame me, I
must also mention
the Neo FreeRunner
device and the
OpenMoko project.
This was a noble experiment: a freely specified hardware platform running
100% FLOSS. I used an OpenMoko FreeRunner myself, hoping that it would be
the mobile phone our community could rally around. I do think the device
and its (various) software stack(s) have a future as an experimental,
hobbyist device. But, just as GNU/Linux needed to focus on x86 hardware
to succeed, so must software freedom efforts in mobile systems focus on
mass-market, widely used, and widely available hardware.

Jailbreaking and the Self-Installed System

When some of us at my day-job office decided to move as close to a
software freedom phone platform as we could, we picked Android/Linux and
the HTC Dream. However, we carefully considered the idea of permission to
run one’s own software on the device. In the desktop and server system
market, this is not a concern, but on mobile systems, it is a central
question.

The holdover of those carrier-controlled agreements for phone
acquisition is the demand that devices be locked down. Devices are locked
down first to a single carrier’s network, so that devices cannot (legally)
be resold as phones ready for any network. Second, carriers believe that
they must fear the FCC if device operating systems can be reinstalled.

On the first point, Google is our best ally in this
regard. The
HTC Dream developer models, called the Android Dev Phone 1 (aka ADP1),
while somewhat more expensive than T-Mobile branded G1s, permit the user
to install any operating system on the phone, and the purchase agreement
extract no promises from the purchaser regarding what software runs on the
device. Google has no interest in locking you to a single carrier, but
only to a single Google experience application vendor. Offering a user
“carrier freedom of choice”, while tying those users tighter
to Google applications, is probably a central part of their marketing
plans.

The second point — fear of an FCC crack down when mobile users
have software freedom — is beyond the scope of this
article. However, what Atheros has done with their Wifi devices shows that
software freedom and FCC compliance can co-exist. Furthermore, the
central piece of FCC’s concern — the GSM chipset and firmware
— runs on a separate processor in modern mobile devices. This is a
software freedom battle for another day, but it shows that the FCC can be
pacified in the meantime by keeping the GSM device a black box to the Free
Software running on the primary processor of the device.

Conclusion

Seeking software freedom on mobile devices will remain a complicated
endeavor for some time. Our community should utilize the FLOSS releases
from companies, but should not forget that, until viable community forks
exist, software freedom on these devices exists at the whim of these
companies. A traditional “get some volunteers together and write
some code” approach can achieve great advancement toward
community-oriented FLOSS systems on mobile devices. Developers could
initially focus on applications for the existing “mostly
FLOSS” platforms of MeeGo and Android/Linux. The challenging and
more urgent work is to replace lower-level proprietary components on these
systems with FLOSS alternatives, but admittedly needs special programming
skills that aren’t easy to find.

(This blog post first appeared
as an
article in
the March
2010 issue of the Canadian online
journal, The Open Source Business Resource.)

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2010/03/04/mobile.html

I started using GNU/Linux and Free Software in 1992. In those days,
while everything I needed for a working computer was generally available
in software freedom, there were many components and applications that
simply did not exist. For highly technical users who did not need many
peripherals, the Free Software community had reached a state of complete
software freedom. Yet, in 1992, everyone agreed there was still much work
to be done. Even today, we still strive for a desktop and server
operating system, with all relevant applications, that grants complete
software freedom.

Looked at broadly, mobile telephone systems are not all that different
from 1992-era GNU/Linux systems. The basics are currently available as
Free, Libre, and Open Source Software (FLOSS). If you need only the bare
minimum of functionality, you can, by picking the right phone hardware,
run an almost completely FLOSS operating system and application set. Yet,
we have so far to go. This post discusses the current penetration of
FLOSS in mobile devices and offers a path forward for free software
advocates.

A Brief History

The mobile telephone market has never functioned like the traditional
computer market. Historically, the mobile user made arrangements with some
network carrier through a long-term contract. That carrier
“gave” the user a phone or discounted it as a loss-leader. Under
that system, few people take their phone hardware choice all that
seriously. Perhaps users pay a bit more for a slightly better phone, but
generally they nearly always pick among the limited choices provided by
the given carrier.

Meanwhile, Research in Motion was the first to provide
corporate-slave-oriented email-enabled devices. Indeed, with the very
recent focus on consumer-oriented devices like the iPhone, most users
forget that Apple is by far not the preferred fruit for the smart phone
user. Today, most people using a “smart phone” are using one
given to them by their employer to chain them to their office email 24/7.

Apple, excellent at manipulating users into paying more for a product
merely because it is shiny, also convinced everyone that now a phone
should be paid for separately, and contracts should go even longer. The
“race to mediocrity” of the phone market has ended. Phones
need real features to stand out. Phones, in fact, aren’t phones
anymore. They are small mobile computers that can also make phone calls.

If these small computers had been introduced in 1992, I suppose I’d be
left writing the Mobile GNU Manifesto, calling for developers
to start from scratch writing operating systems for these new computers,
so that all users could have software freedom. Fortunately, we have
instead been given a head start. Unlike in 1992, not every company in the
market today is completely against releasing Free Software. Specifically,
two companies have seen some value in releasing (some parts of) phone
operating systems as Free Software: Nokia and Google. However, the two
companies have done this for radically different reasons.

The Current State of Mobile Software Freedom

For its part, Nokia likely benefited greatly from the traditional
carrier system. Most of their phones were provided relatively cheaply with
contracts. Their interest in software freedom was limited and perhaps even
non-existent. Nokia sold new hardware every time a phone contract was
renewed, and the carrier paid the difference between the loss-leader price
and Nokia’s wholesale cost. The software on the devices was simple and
mostly internally developed. What incentive did Nokia have to release
software in software freedom? (Nokia realized too late this was the wrong
position, but more on that later.)

In parallel, Nokia had chased another market that I’ve never fully
understood: the tablet PC. Not big enough to be a real computer, but too
large to be a phone, these devices have been an idea looking for a user
base. Regardless of my personal views on these systems, though, GNU/Linux
remains the ideal system for these devices, and Nokia saw that. Nokia
built the Debian-ish Maemo system as a
tablet system, with no phone. However, I can count on one hand all the
people I’ve met who bothered with these devices; I just don’t think a
phone-less small computer is going to ever become the rage, even if Apple
dumps billions into marketing the iPad. (Anyone remember the Newton?)

I cannot explain, nor do I even understand, why Nokia took so long to
use Maemo as a platform for a tablet-like telephone. But, a few months
ago, they finally released
one. This N900 is among only a
few available phones that make any strides toward a fully free software
phone platform. Yet,
the list of
proprietary components required for operation remains quite long. The
common joke is that you can’t even charge the battery on your N900 without
proprietary software.

While there are surely people inside Nokia who want more software
freedom on their devices, Nokia is fundamentally a hardware company
experimenting with software freedom in hopes that it will bolster hardware
sales. Convincing Nokia to shorten that proprietary list will prove
difficult, and the community based effort to replace that long list with
FLOSS (called Mer) faces many
challenges. (These challenges will likely increase with the recent Maemo
merger with Moblin to form MeeGo).

Fortunately, hardware companies are not the only entity interested in
phone operating systems. Google, ever-focused on routing human eyes to its
controlled advertising, realizes that even more eyes will be on mobile
computing platforms in the future. With this goal in mind, Google released
the Android/Linux system, now available on a variety of phones in varying
degrees of software freedom.

Google’s motives are completely different than Nokia’s. Technically,
Google has no hardware to sell. They do have a set of proprietary
applications that yield the “Google online experience” to
deliver Google’s advertising. From Google’s point of view, an
easy-to-adopt, licensing-unencumbered platform will broaden their
advertising market.

Thus, Android/Linux is a nearly fully non-copylefted phone operating
system platform where Linux is the only GPL licensed component essential
to Android’s operation. Ideally, Google wants to see Android adopted
broadly in both Free Software and mixed Free/proprietary deployments.
Google’s goals do not match that of the software freedom community, so in
some cases, a given Android/Linux device will give the user more software
freedom than the N900, but in many cases it will give much less.

The HTC
Dream is the only Android/Linux device I know of where a careful
examination of the necessary proprietary components have been
analyzed. Obviously, the “Google experience” applications are
proprietary. There also
are about
20 hardware interface libraries that do not have source code available
in a public repository. However, when lined up against the N900 with
Maemo, Android on the HTC Dream can be used as an operational mobile
telephone and 3G Internet device using only three proprietary components:
a proprietary GSM firmware, proprietary Wifi firmware, and two audio
interface libraries. Further proprietary components are needed if you
want a working accelerometer, camera, and video codecs as their hardware
interface libraries are all proprietary.

Based on this analysis, it appears that the HTC Dream currently gives
the most software freedom among Android/Linux deployments. It is unlikely
that Google wants anything besides their applications to be proprietary.
While Google has been unresponsive when asked why these hardware interface
libraries are proprietary, it is likely that HTC, the hardware maker with
whom Google contracted, insisted that these components remain proprietary,
and perhaps
fear patent
suits like the one filed this week are to blame here. Meanwhile,
while no detailed analysis of
the Nexus One is yet available,
it’s likely similar to the HTC Dream.

Other Android/Linux devices are now available, such as those from
Motorola and Samsung. There appears to have been no detailed analysis done
yet on the relative proprietary/freeness ratio of these Android
deployments. One can surmise that since these devices are from
traditionally proprietary hardware makers, it is unlikely that these
platforms are freer than those available from Google, whose maximal
interest in a freely available operating system is clear and in contrast
to the traditional desires of hardware makers.

Whether the software is from a hardware-maker desperately trying a new
hardware sales strategy, or an advertising salesman who wants some
influence over an operating system choice to improve ad delivery, the
software freedom community cannot assume that the stewards of these
codebases have the interests of the user community at heart. Indeed, the
interests between these disparate groups will only occasionally be
aligned. Community-oriented forks, as has begun in the Maemo community
with Mer, must also begin in the Android/Linux space too. We are slowly
trying with
the Replicant
project, founded by myself and my colleague Aaron Williamson.

A healthy community-oriented phone operating system project will
ultimately be an essential component to software freedom on these devices.
For example, consider the fate of the Mer project now that Nokia has
announced the merger of Maemo with Moblin. Mer does seek to cherry-pick
from various small device systems, but its focus was to create a freer
Maemo that worked on more devices. Mer now must choose between following
the Maemo in the merge with Moblin, or becoming a true fork. Ideally, the
right outcome for software freedom is a community-led effort, but there
may not be enough community interest, time and commitment to shepherd a
fork while Intel and Nokia push forward on a corporate-controlled
codebase. Further, Moblin will likely push the MeeGo project toward more
of a tablet-PC operating system than a smart phone.

A community-oriented Android/Linux fork has more hope. Google has
little to lose by encouraging and even assisting with such forks; such
effort would actually be wholly consistent with Google’s goals for wider
adoption of platforms that allow deployment of Google’s proprietary
applications. I expect that operating system
software-freedom-motivated efforts will be met with more support from
Google than from Nokia and/or Intel.

However, any operating system, even a mobile device one, needs many
applications to be useful. Google experience applications for
Android/Linux are merely the beginning of the plethora of proprietary
applications that will ultimately be available for MeeGo and Android/Linux
platforms. For FLOSS developers who don’t have a talent for low-level
device libraries and operating system software, these applications
represent a straightforward contribution towards mobile software
freedom. (Obviously, though, if one does have talent for low-level
programming, replacing the proprietary .so’s on Android/Linux would be the
optimal contribution.)

Indeed, on this point, we can take a page from Free Software history.
From the early 1990s onward, fully free GNU/Linux systems succeeded as
viable desktop and server systems because disparate groups of developers
focused simultaneously on both operating systems and application software.
We need that simultaneous diversity of improvement to actually compete
with the fully proprietary alternatives, and to ensure that the
“mostly FLOSS” systems of today are not the “barely
FLOSS” systems of tomorrow.

Careful readers have likely noticed that I have ignored Nokia’s other
release, the Symbian> codebase. Every time I write or speak about the
issues of software freedom in mobile devices, I’m chastised for leaving it
out of the story. My answer is always simple: when a FLOSS version of
Symbian can be compiled from source code, using a FLOSS compiler or SDK,
and that binary can be installed onto an actual working mobile phone
device, then (and only then) will I believe that the Symbian source
release has value beyond historical interest. We have to get honest as a
community about the future of Symbian: it’s a ten-year-old proprietary
codebase designed for devices of that era that doesn’t bootstrap with any
compilers our community uses regularly. Unless there’s a radical change
to these facts, the code belongs in a museum, not running on a phone.

Also, lest my own community of hard-core FLOSS advocates flame me, I
must also mention
the Neo FreeRunner
device and the
OpenMoko project.
This was a noble experiment: a freely specified hardware platform running
100% FLOSS. I used an OpenMoko FreeRunner myself, hoping that it would be
the mobile phone our community could rally around. I do think the device
and its (various) software stack(s) have a future as an experimental,
hobbyist device. But, just as GNU/Linux needed to focus on x86 hardware
to succeed, so must software freedom efforts in mobile systems focus on
mass-market, widely used, and widely available hardware.

Jailbreaking and the Self-Installed System

When some of us at my day-job office decided to move as close to a
software freedom phone platform as we could, we picked Android/Linux and
the HTC Dream. However, we carefully considered the idea of permission to
run one’s own software on the device. In the desktop and server system
market, this is not a concern, but on mobile systems, it is a central
question.

The holdover of those carrier-controlled agreements for phone
acquisition is the demand that devices be locked down. Devices are locked
down first to a single carrier’s network, so that devices cannot (legally)
be resold as phones ready for any network. Second, carriers believe that
they must fear the FCC if device operating systems can be reinstalled.

On the first point, Google is our best ally in this
regard. The
HTC Dream developer models, called the Android Dev Phone 1 (aka ADP1),
while somewhat more expensive than T-Mobile branded G1s, permit the user
to install any operating system on the phone, and the purchase agreement
extract no promises from the purchaser regarding what software runs on the
device. Google has no interest in locking you to a single carrier, but
only to a single Google experience application vendor. Offering a user
“carrier freedom of choice”, while tying those users tighter
to Google applications, is probably a central part of their marketing
plans.

The second point — fear of an FCC crack down when mobile users
have software freedom — is beyond the scope of this
article. However, what Atheros has done with their Wifi devices shows that
software freedom and FCC compliance can co-exist. Furthermore, the
central piece of FCC’s concern — the GSM chipset and firmware
— runs on a separate processor in modern mobile devices. This is a
software freedom battle for another day, but it shows that the FCC can be
pacified in the meantime by keeping the GSM device a black box to the Free
Software running on the primary processor of the device.

Conclusion

Seeking software freedom on mobile devices will remain a complicated
endeavor for some time. Our community should utilize the FLOSS releases
from companies, but should not forget that, until viable community forks
exist, software freedom on these devices exists at the whim of these
companies. A traditional “get some volunteers together and write
some code” approach can achieve great advancement toward
community-oriented FLOSS systems on mobile devices. Developers could
initially focus on applications for the existing “mostly
FLOSS” platforms of MeeGo and Android/Linux. The challenging and
more urgent work is to replace lower-level proprietary components on these
systems with FLOSS alternatives, but admittedly needs special programming
skills that aren’t easy to find.

(This blog post first appeared
as an
article in
the March
2010 issue of the Canadian online
journal, The Open Source Business Resource.)

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2010/03/04/mobile.html

I started using GNU/Linux and Free Software in 1992. In those days,
while everything I needed for a working computer was generally available
in software freedom, there were many components and applications that
simply did not exist. For highly technical users who did not need many
peripherals, the Free Software community had reached a state of complete
software freedom. Yet, in 1992, everyone agreed there was still much work
to be done. Even today, we still strive for a desktop and server
operating system, with all relevant applications, that grants complete
software freedom.

Looked at broadly, mobile telephone systems are not all that different
from 1992-era GNU/Linux systems. The basics are currently available as
Free, Libre, and Open Source Software (FLOSS). If you need only the bare
minimum of functionality, you can, by picking the right phone hardware,
run an almost completely FLOSS operating system and application set. Yet,
we have so far to go. This post discusses the current penetration of
FLOSS in mobile devices and offers a path forward for free software
advocates.

A Brief History

The mobile telephone market has never functioned like the traditional
computer market. Historically, the mobile user made arrangements with some
network carrier through a long-term contract. That carrier
“gave” the user a phone or discounted it as a loss-leader. Under
that system, few people take their phone hardware choice all that
seriously. Perhaps users pay a bit more for a slightly better phone, but
generally they nearly always pick among the limited choices provided by
the given carrier.

Meanwhile, Research in Motion was the first to provide
corporate-slave-oriented email-enabled devices. Indeed, with the very
recent focus on consumer-oriented devices like the iPhone, most users
forget that Apple is by far not the preferred fruit for the smart phone
user. Today, most people using a “smart phone” are using one
given to them by their employer to chain them to their office email 24/7.

Apple, excellent at manipulating users into paying more for a product
merely because it is shiny, also convinced everyone that now a phone
should be paid for separately, and contracts should go even longer. The
“race to mediocrity” of the phone market has ended. Phones
need real features to stand out. Phones, in fact, aren’t phones
anymore. They are small mobile computers that can also make phone calls.

If these small computers had been introduced in 1992, I suppose I’d be
left writing the Mobile GNU Manifesto, calling for developers
to start from scratch writing operating systems for these new computers,
so that all users could have software freedom. Fortunately, we have
instead been given a head start. Unlike in 1992, not every company in the
market today is completely against releasing Free Software. Specifically,
two companies have seen some value in releasing (some parts of) phone
operating systems as Free Software: Nokia and Google. However, the two
companies have done this for radically different reasons.

The Current State of Mobile Software Freedom

For its part, Nokia likely benefited greatly from the traditional
carrier system. Most of their phones were provided relatively cheaply with
contracts. Their interest in software freedom was limited and perhaps even
non-existent. Nokia sold new hardware every time a phone contract was
renewed, and the carrier paid the difference between the loss-leader price
and Nokia’s wholesale cost. The software on the devices was simple and
mostly internally developed. What incentive did Nokia have to release
software in software freedom? (Nokia realized too late this was the wrong
position, but more on that later.)

In parallel, Nokia had chased another market that I’ve never fully
understood: the tablet PC. Not big enough to be a real computer, but too
large to be a phone, these devices have been an idea looking for a user
base. Regardless of my personal views on these systems, though, GNU/Linux
remains the ideal system for these devices, and Nokia saw that. Nokia
built the Debian-ish Maemo system as a
tablet system, with no phone. However, I can count on one hand all the
people I’ve met who bothered with these devices; I just don’t think a
phone-less small computer is going to ever become the rage, even if Apple
dumps billions into marketing the iPad. (Anyone remember the Newton?)

I cannot explain, nor do I even understand, why Nokia took so long to
use Maemo as a platform for a tablet-like telephone. But, a few months
ago, they finally released
one. This N900 is among only a
few available phones that make any strides toward a fully free software
phone platform. Yet,
the list of
proprietary components required for operation remains quite long. The
common joke is that you can’t even charge the battery on your N900 without
proprietary software.

While there are surely people inside Nokia who want more software
freedom on their devices, Nokia is fundamentally a hardware company
experimenting with software freedom in hopes that it will bolster hardware
sales. Convincing Nokia to shorten that proprietary list will prove
difficult, and the community based effort to replace that long list with
FLOSS (called Mer) faces many
challenges. (These challenges will likely increase with the recent Maemo
merger with Moblin to form MeeGo).

Fortunately, hardware companies are not the only entity interested in
phone operating systems. Google, ever-focused on routing human eyes to its
controlled advertising, realizes that even more eyes will be on mobile
computing platforms in the future. With this goal in mind, Google released
the Android/Linux system, now available on a variety of phones in varying
degrees of software freedom.

Google’s motives are completely different than Nokia’s. Technically,
Google has no hardware to sell. They do have a set of proprietary
applications that yield the “Google online experience” to
deliver Google’s advertising. From Google’s point of view, an
easy-to-adopt, licensing-unencumbered platform will broaden their
advertising market.

Thus, Android/Linux is a nearly fully non-copylefted phone operating
system platform where Linux is the only GPL licensed component essential
to Android’s operation. Ideally, Google wants to see Android adopted
broadly in both Free Software and mixed Free/proprietary deployments.
Google’s goals do not match that of the software freedom community, so in
some cases, a given Android/Linux device will give the user more software
freedom than the N900, but in many cases it will give much less.

The HTC
Dream is the only Android/Linux device I know of where a careful
examination of the necessary proprietary components have been
analyzed. Obviously, the “Google experience” applications are
proprietary. There also
are about
20 hardware interface libraries that do not have source code available
in a public repository. However, when lined up against the N900 with
Maemo, Android on the HTC Dream can be used as an operational mobile
telephone and 3G Internet device using only three proprietary components:
a proprietary GSM firmware, proprietary Wifi firmware, and two audio
interface libraries. Further proprietary components are needed if you
want a working accelerometer, camera, and video codecs as their hardware
interface libraries are all proprietary.

Based on this analysis, it appears that the HTC Dream currently gives
the most software freedom among Android/Linux deployments. It is unlikely
that Google wants anything besides their applications to be proprietary.
While Google has been unresponsive when asked why these hardware interface
libraries are proprietary, it is likely that HTC, the hardware maker with
whom Google contracted, insisted that these components remain proprietary,
and perhaps
fear patent
suits like the one filed this week are to blame here. Meanwhile,
while no detailed analysis of
the Nexus One is yet available,
it’s likely similar to the HTC Dream.

Other Android/Linux devices are now available, such as those from
Motorola and Samsung. There appears to have been no detailed analysis done
yet on the relative proprietary/freeness ratio of these Android
deployments. One can surmise that since these devices are from
traditionally proprietary hardware makers, it is unlikely that these
platforms are freer than those available from Google, whose maximal
interest in a freely available operating system is clear and in contrast
to the traditional desires of hardware makers.

Whether the software is from a hardware-maker desperately trying a new
hardware sales strategy, or an advertising salesman who wants some
influence over an operating system choice to improve ad delivery, the
software freedom community cannot assume that the stewards of these
codebases have the interests of the user community at heart. Indeed, the
interests between these disparate groups will only occasionally be
aligned. Community-oriented forks, as has begun in the Maemo community
with Mer, must also begin in the Android/Linux space too. We are slowly
trying with
the Replicant
project, founded by myself and my colleague Aaron Williamson.

A healthy community-oriented phone operating system project will
ultimately be an essential component to software freedom on these devices.
For example, consider the fate of the Mer project now that Nokia has
announced the merger of Maemo with Moblin. Mer does seek to cherry-pick
from various small device systems, but its focus was to create a freer
Maemo that worked on more devices. Mer now must choose between following
the Maemo in the merge with Moblin, or becoming a true fork. Ideally, the
right outcome for software freedom is a community-led effort, but there
may not be enough community interest, time and commitment to shepherd a
fork while Intel and Nokia push forward on a corporate-controlled
codebase. Further, Moblin will likely push the MeeGo project toward more
of a tablet-PC operating system than a smart phone.

A community-oriented Android/Linux fork has more hope. Google has
little to lose by encouraging and even assisting with such forks; such
effort would actually be wholly consistent with Google’s goals for wider
adoption of platforms that allow deployment of Google’s proprietary
applications. I expect that operating system
software-freedom-motivated efforts will be met with more support from
Google than from Nokia and/or Intel.

However, any operating system, even a mobile device one, needs many
applications to be useful. Google experience applications for
Android/Linux are merely the beginning of the plethora of proprietary
applications that will ultimately be available for MeeGo and Android/Linux
platforms. For FLOSS developers who don’t have a talent for low-level
device libraries and operating system software, these applications
represent a straightforward contribution towards mobile software
freedom. (Obviously, though, if one does have talent for low-level
programming, replacing the proprietary .so’s on Android/Linux would be the
optimal contribution.)

Indeed, on this point, we can take a page from Free Software history.
From the early 1990s onward, fully free GNU/Linux systems succeeded as
viable desktop and server systems because disparate groups of developers
focused simultaneously on both operating systems and application software.
We need that simultaneous diversity of improvement to actually compete
with the fully proprietary alternatives, and to ensure that the
“mostly FLOSS” systems of today are not the “barely
FLOSS” systems of tomorrow.

Careful readers have likely noticed that I have ignored Nokia’s other
release, the Symbian> codebase. Every time I write or speak about the
issues of software freedom in mobile devices, I’m chastised for leaving it
out of the story. My answer is always simple: when a FLOSS version of
Symbian can be compiled from source code, using a FLOSS compiler or SDK,
and that binary can be installed onto an actual working mobile phone
device, then (and only then) will I believe that the Symbian source
release has value beyond historical interest. We have to get honest as a
community about the future of Symbian: it’s a ten-year-old proprietary
codebase designed for devices of that era that doesn’t bootstrap with any
compilers our community uses regularly. Unless there’s a radical change
to these facts, the code belongs in a museum, not running on a phone.

Also, lest my own community of hard-core FLOSS advocates flame me, I
must also mention
the Neo FreeRunner
device and the
OpenMoko project.
This was a noble experiment: a freely specified hardware platform running
100% FLOSS. I used an OpenMoko FreeRunner myself, hoping that it would be
the mobile phone our community could rally around. I do think the device
and its (various) software stack(s) have a future as an experimental,
hobbyist device. But, just as GNU/Linux needed to focus on x86 hardware
to succeed, so must software freedom efforts in mobile systems focus on
mass-market, widely used, and widely available hardware.

Jailbreaking and the Self-Installed System

When some of us at my day-job office decided to move as close to a
software freedom phone platform as we could, we picked Android/Linux and
the HTC Dream. However, we carefully considered the idea of permission to
run one’s own software on the device. In the desktop and server system
market, this is not a concern, but on mobile systems, it is a central
question.

The holdover of those carrier-controlled agreements for phone
acquisition is the demand that devices be locked down. Devices are locked
down first to a single carrier’s network, so that devices cannot (legally)
be resold as phones ready for any network. Second, carriers believe that
they must fear the FCC if device operating systems can be reinstalled.

On the first point, Google is our best ally in this
regard. The
HTC Dream developer models, called the Android Dev Phone 1 (aka ADP1),
while somewhat more expensive than T-Mobile branded G1s, permit the user
to install any operating system on the phone, and the purchase agreement
extract no promises from the purchaser regarding what software runs on the
device. Google has no interest in locking you to a single carrier, but
only to a single Google experience application vendor. Offering a user
“carrier freedom of choice”, while tying those users tighter
to Google applications, is probably a central part of their marketing
plans.

The second point — fear of an FCC crack down when mobile users
have software freedom — is beyond the scope of this
article. However, what Atheros has done with their Wifi devices shows that
software freedom and FCC compliance can co-exist. Furthermore, the
central piece of FCC’s concern — the GSM chipset and firmware
— runs on a separate processor in modern mobile devices. This is a
software freedom battle for another day, but it shows that the FCC can be
pacified in the meantime by keeping the GSM device a black box to the Free
Software running on the primary processor of the device.

Conclusion

Seeking software freedom on mobile devices will remain a complicated
endeavor for some time. Our community should utilize the FLOSS releases
from companies, but should not forget that, until viable community forks
exist, software freedom on these devices exists at the whim of these
companies. A traditional “get some volunteers together and write
some code” approach can achieve great advancement toward
community-oriented FLOSS systems on mobile devices. Developers could
initially focus on applications for the existing “mostly
FLOSS” platforms of MeeGo and Android/Linux. The challenging and
more urgent work is to replace lower-level proprietary components on these
systems with FLOSS alternatives, but admittedly needs special programming
skills that aren’t easy to find.

(This blog post first appeared
as an
article in
the March
2010 issue of the Canadian online
journal, The Open Source Business Resource.)

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2010/03/04/mobile.html

I started using GNU/Linux and Free Software in 1992. In those days,
while everything I needed for a working computer was generally available
in software freedom, there were many components and applications that
simply did not exist. For highly technical users who did not need many
peripherals, the Free Software community had reached a state of complete
software freedom. Yet, in 1992, everyone agreed there was still much work
to be done. Even today, we still strive for a desktop and server
operating system, with all relevant applications, that grants complete
software freedom.

Looked at broadly, mobile telephone systems are not all that different
from 1992-era GNU/Linux systems. The basics are currently available as
Free, Libre, and Open Source Software (FLOSS). If you need only the bare
minimum of functionality, you can, by picking the right phone hardware,
run an almost completely FLOSS operating system and application set. Yet,
we have so far to go. This post discusses the current penetration of
FLOSS in mobile devices and offers a path forward for free software
advocates.

A Brief History

The mobile telephone market has never functioned like the traditional
computer market. Historically, the mobile user made arrangements with some
network carrier through a long-term contract. That carrier
“gave” the user a phone or discounted it as a loss-leader. Under
that system, few people take their phone hardware choice all that
seriously. Perhaps users pay a bit more for a slightly better phone, but
generally they nearly always pick among the limited choices provided by
the given carrier.

Meanwhile, Research in Motion was the first to provide
corporate-slave-oriented email-enabled devices. Indeed, with the very
recent focus on consumer-oriented devices like the iPhone, most users
forget that Apple is by far not the preferred fruit for the smart phone
user. Today, most people using a “smart phone” are using one
given to them by their employer to chain them to their office email 24/7.

Apple, excellent at manipulating users into paying more for a product
merely because it is shiny, also convinced everyone that now a phone
should be paid for separately, and contracts should go even longer. The
“race to mediocrity” of the phone market has ended. Phones
need real features to stand out. Phones, in fact, aren’t phones
anymore. They are small mobile computers that can also make phone calls.

If these small computers had been introduced in 1992, I suppose I’d be
left writing the Mobile GNU Manifesto, calling for developers
to start from scratch writing operating systems for these new computers,
so that all users could have software freedom. Fortunately, we have
instead been given a head start. Unlike in 1992, not every company in the
market today is completely against releasing Free Software. Specifically,
two companies have seen some value in releasing (some parts of) phone
operating systems as Free Software: Nokia and Google. However, the two
companies have done this for radically different reasons.

The Current State of Mobile Software Freedom

For its part, Nokia likely benefited greatly from the traditional
carrier system. Most of their phones were provided relatively cheaply with
contracts. Their interest in software freedom was limited and perhaps even
non-existent. Nokia sold new hardware every time a phone contract was
renewed, and the carrier paid the difference between the loss-leader price
and Nokia’s wholesale cost. The software on the devices was simple and
mostly internally developed. What incentive did Nokia have to release
software in software freedom? (Nokia realized too late this was the wrong
position, but more on that later.)

In parallel, Nokia had chased another market that I’ve never fully
understood: the tablet PC. Not big enough to be a real computer, but too
large to be a phone, these devices have been an idea looking for a user
base. Regardless of my personal views on these systems, though, GNU/Linux
remains the ideal system for these devices, and Nokia saw that. Nokia
built the Debian-ish Maemo system as a
tablet system, with no phone. However, I can count on one hand all the
people I’ve met who bothered with these devices; I just don’t think a
phone-less small computer is going to ever become the rage, even if Apple
dumps billions into marketing the iPad. (Anyone remember the Newton?)

I cannot explain, nor do I even understand, why Nokia took so long to
use Maemo as a platform for a tablet-like telephone. But, a few months
ago, they finally released
one. This N900 is among only a
few available phones that make any strides toward a fully free software
phone platform. Yet,
the list of
proprietary components required for operation remains quite long. The
common joke is that you can’t even charge the battery on your N900 without
proprietary software.

While there are surely people inside Nokia who want more software
freedom on their devices, Nokia is fundamentally a hardware company
experimenting with software freedom in hopes that it will bolster hardware
sales. Convincing Nokia to shorten that proprietary list will prove
difficult, and the community based effort to replace that long list with
FLOSS (called Mer) faces many
challenges. (These challenges will likely increase with the recent Maemo
merger with Moblin to form MeeGo).

Fortunately, hardware companies are not the only entity interested in
phone operating systems. Google, ever-focused on routing human eyes to its
controlled advertising, realizes that even more eyes will be on mobile
computing platforms in the future. With this goal in mind, Google released
the Android/Linux system, now available on a variety of phones in varying
degrees of software freedom.

Google’s motives are completely different than Nokia’s. Technically,
Google has no hardware to sell. They do have a set of proprietary
applications that yield the “Google online experience” to
deliver Google’s advertising. From Google’s point of view, an
easy-to-adopt, licensing-unencumbered platform will broaden their
advertising market.

Thus, Android/Linux is a nearly fully non-copylefted phone operating
system platform where Linux is the only GPL licensed component essential
to Android’s operation. Ideally, Google wants to see Android adopted
broadly in both Free Software and mixed Free/proprietary deployments.
Google’s goals do not match that of the software freedom community, so in
some cases, a given Android/Linux device will give the user more software
freedom than the N900, but in many cases it will give much less.

The HTC
Dream is the only Android/Linux device I know of where a careful
examination of the necessary proprietary components have been
analyzed. Obviously, the “Google experience” applications are
proprietary. There also
are about
20 hardware interface libraries that do not have source code available
in a public repository. However, when lined up against the N900 with
Maemo, Android on the HTC Dream can be used as an operational mobile
telephone and 3G Internet device using only three proprietary components:
a proprietary GSM firmware, proprietary Wifi firmware, and two audio
interface libraries. Further proprietary components are needed if you
want a working accelerometer, camera, and video codecs as their hardware
interface libraries are all proprietary.

Based on this analysis, it appears that the HTC Dream currently gives
the most software freedom among Android/Linux deployments. It is unlikely
that Google wants anything besides their applications to be proprietary.
While Google has been unresponsive when asked why these hardware interface
libraries are proprietary, it is likely that HTC, the hardware maker with
whom Google contracted, insisted that these components remain proprietary,
and perhaps
fear patent
suits like the one filed this week are to blame here. Meanwhile,
while no detailed analysis of
the Nexus One is yet available,
it’s likely similar to the HTC Dream.

Other Android/Linux devices are now available, such as those from
Motorola and Samsung. There appears to have been no detailed analysis done
yet on the relative proprietary/freeness ratio of these Android
deployments. One can surmise that since these devices are from
traditionally proprietary hardware makers, it is unlikely that these
platforms are freer than those available from Google, whose maximal
interest in a freely available operating system is clear and in contrast
to the traditional desires of hardware makers.

Whether the software is from a hardware-maker desperately trying a new
hardware sales strategy, or an advertising salesman who wants some
influence over an operating system choice to improve ad delivery, the
software freedom community cannot assume that the stewards of these
codebases have the interests of the user community at heart. Indeed, the
interests between these disparate groups will only occasionally be
aligned. Community-oriented forks, as has begun in the Maemo community
with Mer, must also begin in the Android/Linux space too. We are slowly
trying with
the Replicant
project, founded by myself and my colleague Aaron Williamson.

A healthy community-oriented phone operating system project will
ultimately be an essential component to software freedom on these devices.
For example, consider the fate of the Mer project now that Nokia has
announced the merger of Maemo with Moblin. Mer does seek to cherry-pick
from various small device systems, but its focus was to create a freer
Maemo that worked on more devices. Mer now must choose between following
the Maemo in the merge with Moblin, or becoming a true fork. Ideally, the
right outcome for software freedom is a community-led effort, but there
may not be enough community interest, time and commitment to shepherd a
fork while Intel and Nokia push forward on a corporate-controlled
codebase. Further, Moblin will likely push the MeeGo project toward more
of a tablet-PC operating system than a smart phone.

A community-oriented Android/Linux fork has more hope. Google has
little to lose by encouraging and even assisting with such forks; such
effort would actually be wholly consistent with Google’s goals for wider
adoption of platforms that allow deployment of Google’s proprietary
applications. I expect that operating system
software-freedom-motivated efforts will be met with more support from
Google than from Nokia and/or Intel.

However, any operating system, even a mobile device one, needs many
applications to be useful. Google experience applications for
Android/Linux are merely the beginning of the plethora of proprietary
applications that will ultimately be available for MeeGo and Android/Linux
platforms. For FLOSS developers who don’t have a talent for low-level
device libraries and operating system software, these applications
represent a straightforward contribution towards mobile software
freedom. (Obviously, though, if one does have talent for low-level
programming, replacing the proprietary .so’s on Android/Linux would be the
optimal contribution.)

Indeed, on this point, we can take a page from Free Software history.
From the early 1990s onward, fully free GNU/Linux systems succeeded as
viable desktop and server systems because disparate groups of developers
focused simultaneously on both operating systems and application software.
We need that simultaneous diversity of improvement to actually compete
with the fully proprietary alternatives, and to ensure that the
“mostly FLOSS” systems of today are not the “barely
FLOSS” systems of tomorrow.

Careful readers have likely noticed that I have ignored Nokia’s other
release, the Symbian> codebase. Every time I write or speak about the
issues of software freedom in mobile devices, I’m chastised for leaving it
out of the story. My answer is always simple: when a FLOSS version of
Symbian can be compiled from source code, using a FLOSS compiler or SDK,
and that binary can be installed onto an actual working mobile phone
device, then (and only then) will I believe that the Symbian source
release has value beyond historical interest. We have to get honest as a
community about the future of Symbian: it’s a ten-year-old proprietary
codebase designed for devices of that era that doesn’t bootstrap with any
compilers our community uses regularly. Unless there’s a radical change
to these facts, the code belongs in a museum, not running on a phone.

Also, lest my own community of hard-core FLOSS advocates flame me, I
must also mention
the Neo FreeRunner
device and the
OpenMoko project.
This was a noble experiment: a freely specified hardware platform running
100% FLOSS. I used an OpenMoko FreeRunner myself, hoping that it would be
the mobile phone our community could rally around. I do think the device
and its (various) software stack(s) have a future as an experimental,
hobbyist device. But, just as GNU/Linux needed to focus on x86 hardware
to succeed, so must software freedom efforts in mobile systems focus on
mass-market, widely used, and widely available hardware.

Jailbreaking and the Self-Installed System

When some of us at my day-job office decided to move as close to a
software freedom phone platform as we could, we picked Android/Linux and
the HTC Dream. However, we carefully considered the idea of permission to
run one’s own software on the device. In the desktop and server system
market, this is not a concern, but on mobile systems, it is a central
question.

The holdover of those carrier-controlled agreements for phone
acquisition is the demand that devices be locked down. Devices are locked
down first to a single carrier’s network, so that devices cannot (legally)
be resold as phones ready for any network. Second, carriers believe that
they must fear the FCC if device operating systems can be reinstalled.

On the first point, Google is our best ally in this
regard. The
HTC Dream developer models, called the Android Dev Phone 1 (aka ADP1),
while somewhat more expensive than T-Mobile branded G1s, permit the user
to install any operating system on the phone, and the purchase agreement
extract no promises from the purchaser regarding what software runs on the
device. Google has no interest in locking you to a single carrier, but
only to a single Google experience application vendor. Offering a user
“carrier freedom of choice”, while tying those users tighter
to Google applications, is probably a central part of their marketing
plans.

The second point — fear of an FCC crack down when mobile users
have software freedom — is beyond the scope of this
article. However, what Atheros has done with their Wifi devices shows that
software freedom and FCC compliance can co-exist. Furthermore, the
central piece of FCC’s concern — the GSM chipset and firmware
— runs on a separate processor in modern mobile devices. This is a
software freedom battle for another day, but it shows that the FCC can be
pacified in the meantime by keeping the GSM device a black box to the Free
Software running on the primary processor of the device.

Conclusion

Seeking software freedom on mobile devices will remain a complicated
endeavor for some time. Our community should utilize the FLOSS releases
from companies, but should not forget that, until viable community forks
exist, software freedom on these devices exists at the whim of these
companies. A traditional “get some volunteers together and write
some code” approach can achieve great advancement toward
community-oriented FLOSS systems on mobile devices. Developers could
initially focus on applications for the existing “mostly
FLOSS” platforms of MeeGo and Android/Linux. The challenging and
more urgent work is to replace lower-level proprietary components on these
systems with FLOSS alternatives, but admittedly needs special programming
skills that aren’t easy to find.

(This blog post first appeared
as an
article in
the March
2010 issue of the Canadian online
journal, The Open Source Business Resource.)

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2010/03/04/mobile.html

I started using GNU/Linux and Free Software in 1992. In those days,
while everything I needed for a working computer was generally available
in software freedom, there were many components and applications that
simply did not exist. For highly technical users who did not need many
peripherals, the Free Software community had reached a state of complete
software freedom. Yet, in 1992, everyone agreed there was still much work
to be done. Even today, we still strive for a desktop and server
operating system, with all relevant applications, that grants complete
software freedom.

Looked at broadly, mobile telephone systems are not all that different
from 1992-era GNU/Linux systems. The basics are currently available as
Free, Libre, and Open Source Software (FLOSS). If you need only the bare
minimum of functionality, you can, by picking the right phone hardware,
run an almost completely FLOSS operating system and application set. Yet,
we have so far to go. This post discusses the current penetration of
FLOSS in mobile devices and offers a path forward for free software
advocates.

A Brief History

The mobile telephone market has never functioned like the traditional
computer market. Historically, the mobile user made arrangements with some
network carrier through a long-term contract. That carrier
“gave” the user a phone or discounted it as a loss-leader. Under
that system, few people take their phone hardware choice all that
seriously. Perhaps users pay a bit more for a slightly better phone, but
generally they nearly always pick among the limited choices provided by
the given carrier.

Meanwhile, Research in Motion was the first to provide
corporate-slave-oriented email-enabled devices. Indeed, with the very
recent focus on consumer-oriented devices like the iPhone, most users
forget that Apple is by far not the preferred fruit for the smart phone
user. Today, most people using a “smart phone” are using one
given to them by their employer to chain them to their office email 24/7.

Apple, excellent at manipulating users into paying more for a product
merely because it is shiny, also convinced everyone that now a phone
should be paid for separately, and contracts should go even longer. The
“race to mediocrity” of the phone market has ended. Phones
need real features to stand out. Phones, in fact, aren’t phones
anymore. They are small mobile computers that can also make phone calls.

If these small computers had been introduced in 1992, I suppose I’d be
left writing the Mobile GNU Manifesto, calling for developers
to start from scratch writing operating systems for these new computers,
so that all users could have software freedom. Fortunately, we have
instead been given a head start. Unlike in 1992, not every company in the
market today is completely against releasing Free Software. Specifically,
two companies have seen some value in releasing (some parts of) phone
operating systems as Free Software: Nokia and Google. However, the two
companies have done this for radically different reasons.

The Current State of Mobile Software Freedom

For its part, Nokia likely benefited greatly from the traditional
carrier system. Most of their phones were provided relatively cheaply with
contracts. Their interest in software freedom was limited and perhaps even
non-existent. Nokia sold new hardware every time a phone contract was
renewed, and the carrier paid the difference between the loss-leader price
and Nokia’s wholesale cost. The software on the devices was simple and
mostly internally developed. What incentive did Nokia have to release
software in software freedom? (Nokia realized too late this was the wrong
position, but more on that later.)

In parallel, Nokia had chased another market that I’ve never fully
understood: the tablet PC. Not big enough to be a real computer, but too
large to be a phone, these devices have been an idea looking for a user
base. Regardless of my personal views on these systems, though, GNU/Linux
remains the ideal system for these devices, and Nokia saw that. Nokia
built the Debian-ish Maemo system as a
tablet system, with no phone. However, I can count on one hand all the
people I’ve met who bothered with these devices; I just don’t think a
phone-less small computer is going to ever become the rage, even if Apple
dumps billions into marketing the iPad. (Anyone remember the Newton?)

I cannot explain, nor do I even understand, why Nokia took so long to
use Maemo as a platform for a tablet-like telephone. But, a few months
ago, they finally released
one. This N900 is among only a
few available phones that make any strides toward a fully free software
phone platform. Yet,
the list of
proprietary components required for operation remains quite long. The
common joke is that you can’t even charge the battery on your N900 without
proprietary software.

While there are surely people inside Nokia who want more software
freedom on their devices, Nokia is fundamentally a hardware company
experimenting with software freedom in hopes that it will bolster hardware
sales. Convincing Nokia to shorten that proprietary list will prove
difficult, and the community based effort to replace that long list with
FLOSS (called Mer) faces many
challenges. (These challenges will likely increase with the recent Maemo
merger with Moblin to form MeeGo).

Fortunately, hardware companies are not the only entity interested in
phone operating systems. Google, ever-focused on routing human eyes to its
controlled advertising, realizes that even more eyes will be on mobile
computing platforms in the future. With this goal in mind, Google released
the Android/Linux system, now available on a variety of phones in varying
degrees of software freedom.

Google’s motives are completely different than Nokia’s. Technically,
Google has no hardware to sell. They do have a set of proprietary
applications that yield the “Google online experience” to
deliver Google’s advertising. From Google’s point of view, an
easy-to-adopt, licensing-unencumbered platform will broaden their
advertising market.

Thus, Android/Linux is a nearly fully non-copylefted phone operating
system platform where Linux is the only GPL licensed component essential
to Android’s operation. Ideally, Google wants to see Android adopted
broadly in both Free Software and mixed Free/proprietary deployments.
Google’s goals do not match that of the software freedom community, so in
some cases, a given Android/Linux device will give the user more software
freedom than the N900, but in many cases it will give much less.

The HTC
Dream is the only Android/Linux device I know of where a careful
examination of the necessary proprietary components have been
analyzed. Obviously, the “Google experience” applications are
proprietary. There also
are about
20 hardware interface libraries that do not have source code available
in a public repository. However, when lined up against the N900 with
Maemo, Android on the HTC Dream can be used as an operational mobile
telephone and 3G Internet device using only three proprietary components:
a proprietary GSM firmware, proprietary Wifi firmware, and two audio
interface libraries. Further proprietary components are needed if you
want a working accelerometer, camera, and video codecs as their hardware
interface libraries are all proprietary.

Based on this analysis, it appears that the HTC Dream currently gives
the most software freedom among Android/Linux deployments. It is unlikely
that Google wants anything besides their applications to be proprietary.
While Google has been unresponsive when asked why these hardware interface
libraries are proprietary, it is likely that HTC, the hardware maker with
whom Google contracted, insisted that these components remain proprietary,
and perhaps
fear patent
suits like the one filed this week are to blame here. Meanwhile,
while no detailed analysis of
the Nexus One is yet available,
it’s likely similar to the HTC Dream.

Other Android/Linux devices are now available, such as those from
Motorola and Samsung. There appears to have been no detailed analysis done
yet on the relative proprietary/freeness ratio of these Android
deployments. One can surmise that since these devices are from
traditionally proprietary hardware makers, it is unlikely that these
platforms are freer than those available from Google, whose maximal
interest in a freely available operating system is clear and in contrast
to the traditional desires of hardware makers.

Whether the software is from a hardware-maker desperately trying a new
hardware sales strategy, or an advertising salesman who wants some
influence over an operating system choice to improve ad delivery, the
software freedom community cannot assume that the stewards of these
codebases have the interests of the user community at heart. Indeed, the
interests between these disparate groups will only occasionally be
aligned. Community-oriented forks, as has begun in the Maemo community
with Mer, must also begin in the Android/Linux space too. We are slowly
trying with
the Replicant
project, founded by myself and my colleague Aaron Williamson.

A healthy community-oriented phone operating system project will
ultimately be an essential component to software freedom on these devices.
For example, consider the fate of the Mer project now that Nokia has
announced the merger of Maemo with Moblin. Mer does seek to cherry-pick
from various small device systems, but its focus was to create a freer
Maemo that worked on more devices. Mer now must choose between following
the Maemo in the merge with Moblin, or becoming a true fork. Ideally, the
right outcome for software freedom is a community-led effort, but there
may not be enough community interest, time and commitment to shepherd a
fork while Intel and Nokia push forward on a corporate-controlled
codebase. Further, Moblin will likely push the MeeGo project toward more
of a tablet-PC operating system than a smart phone.

A community-oriented Android/Linux fork has more hope. Google has
little to lose by encouraging and even assisting with such forks; such
effort would actually be wholly consistent with Google’s goals for wider
adoption of platforms that allow deployment of Google’s proprietary
applications. I expect that operating system
software-freedom-motivated efforts will be met with more support from
Google than from Nokia and/or Intel.

However, any operating system, even a mobile device one, needs many
applications to be useful. Google experience applications for
Android/Linux are merely the beginning of the plethora of proprietary
applications that will ultimately be available for MeeGo and Android/Linux
platforms. For FLOSS developers who don’t have a talent for low-level
device libraries and operating system software, these applications
represent a straightforward contribution towards mobile software
freedom. (Obviously, though, if one does have talent for low-level
programming, replacing the proprietary .so’s on Android/Linux would be the
optimal contribution.)

Indeed, on this point, we can take a page from Free Software history.
From the early 1990s onward, fully free GNU/Linux systems succeeded as
viable desktop and server systems because disparate groups of developers
focused simultaneously on both operating systems and application software.
We need that simultaneous diversity of improvement to actually compete
with the fully proprietary alternatives, and to ensure that the
“mostly FLOSS” systems of today are not the “barely
FLOSS” systems of tomorrow.

Careful readers have likely noticed that I have ignored Nokia’s other
release, the Symbian> codebase. Every time I write or speak about the
issues of software freedom in mobile devices, I’m chastised for leaving it
out of the story. My answer is always simple: when a FLOSS version of
Symbian can be compiled from source code, using a FLOSS compiler or SDK,
and that binary can be installed onto an actual working mobile phone
device, then (and only then) will I believe that the Symbian source
release has value beyond historical interest. We have to get honest as a
community about the future of Symbian: it’s a ten-year-old proprietary
codebase designed for devices of that era that doesn’t bootstrap with any
compilers our community uses regularly. Unless there’s a radical change
to these facts, the code belongs in a museum, not running on a phone.

Also, lest my own community of hard-core FLOSS advocates flame me, I
must also mention
the Neo FreeRunner
device and the
OpenMoko project.
This was a noble experiment: a freely specified hardware platform running
100% FLOSS. I used an OpenMoko FreeRunner myself, hoping that it would be
the mobile phone our community could rally around. I do think the device
and its (various) software stack(s) have a future as an experimental,
hobbyist device. But, just as GNU/Linux needed to focus on x86 hardware
to succeed, so must software freedom efforts in mobile systems focus on
mass-market, widely used, and widely available hardware.

Jailbreaking and the Self-Installed System

When some of us at my day-job office decided to move as close to a
software freedom phone platform as we could, we picked Android/Linux and
the HTC Dream. However, we carefully considered the idea of permission to
run one’s own software on the device. In the desktop and server system
market, this is not a concern, but on mobile systems, it is a central
question.

The holdover of those carrier-controlled agreements for phone
acquisition is the demand that devices be locked down. Devices are locked
down first to a single carrier’s network, so that devices cannot (legally)
be resold as phones ready for any network. Second, carriers believe that
they must fear the FCC if device operating systems can be reinstalled.

On the first point, Google is our best ally in this
regard. The
HTC Dream developer models, called the Android Dev Phone 1 (aka ADP1),
while somewhat more expensive than T-Mobile branded G1s, permit the user
to install any operating system on the phone, and the purchase agreement
extract no promises from the purchaser regarding what software runs on the
device. Google has no interest in locking you to a single carrier, but
only to a single Google experience application vendor. Offering a user
“carrier freedom of choice”, while tying those users tighter
to Google applications, is probably a central part of their marketing
plans.

The second point — fear of an FCC crack down when mobile users
have software freedom — is beyond the scope of this
article. However, what Atheros has done with their Wifi devices shows that
software freedom and FCC compliance can co-exist. Furthermore, the
central piece of FCC’s concern — the GSM chipset and firmware
— runs on a separate processor in modern mobile devices. This is a
software freedom battle for another day, but it shows that the FCC can be
pacified in the meantime by keeping the GSM device a black box to the Free
Software running on the primary processor of the device.

Conclusion

Seeking software freedom on mobile devices will remain a complicated
endeavor for some time. Our community should utilize the FLOSS releases
from companies, but should not forget that, until viable community forks
exist, software freedom on these devices exists at the whim of these
companies. A traditional “get some volunteers together and write
some code” approach can achieve great advancement toward
community-oriented FLOSS systems on mobile devices. Developers could
initially focus on applications for the existing “mostly
FLOSS” platforms of MeeGo and Android/Linux. The challenging and
more urgent work is to replace lower-level proprietary components on these
systems with FLOSS alternatives, but admittedly needs special programming
skills that aren’t easy to find.

(This blog post first appeared
as an
article in
the March
2010 issue of the Canadian online
journal, The Open Source Business Resource.)