Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #5462 > unrolled thread

Re: obviscating python code for distribution

Back to article view | Back to comp.lang.python

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: obviscating python code for distribution Daniel Kluev <dan.kluev@gmail.com> - 2011-05-16 13:21 +1100
    Re: obviscating python code for distribution "Rhodri James" <rhodri@wildebst.demon.co.uk> - 2011-05-16 23:42 +0100
      Re: obviscating python code for distribution Hans Georg Schaathun <hg@schaathun.net> - 2011-05-18 08:36 +0100
        Re: obviscating python code for distribution Dotan Cohen <dotancohen@gmail.com> - 2011-05-18 17:42 +0300
        Re: obviscating python code for distribution geremy condra <debatem1@gmail.com> - 2011-05-18 09:54 -0700
          Re: obviscating python code for distribution Hans Georg Schaathun <hg@schaathun.net> - 2011-05-18 18:33 +0100
            Re: obviscating python code for distribution geremy condra <debatem1@gmail.com> - 2011-05-18 12:07 -0700
              Re: obviscating python code for distribution Hans Georg Schaathun <hg@schaathun.net> - 2011-05-18 20:56 +0100
                Re: obviscating python code for distribution geremy condra <debatem1@gmail.com> - 2011-05-18 14:34 -0700
                  Re: obviscating python code for distribution Hans Georg Schaathun <hg@schaathun.net> - 2011-05-19 06:21 +0100
                    Re: obviscating python code for distribution Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-05-19 08:47 +0000
                      Re: obviscating python code for distribution Hans Georg Schaathun <hg@schaathun.net> - 2011-05-19 10:16 +0100
                    Re: obviscating python code for distribution geremy condra <debatem1@gmail.com> - 2011-05-19 10:23 -0700
                      Re: obviscating python code for distribution Hans Georg Schaathun <hg@schaathun.net> - 2011-05-19 19:23 +0100
                        Re: obviscating python code for distribution geremy condra <debatem1@gmail.com> - 2011-05-19 17:56 -0700
                          Re: obviscating python code for distribution Hans Georg Schaathun <hg@schaathun.net> - 2011-05-20 05:48 +0100
                            Re: obviscating python code for distribution Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-05-20 07:04 +0000
                              Re: obviscating python code for distribution Hans Georg Schaathun <hg@schaathun.net> - 2011-05-20 09:54 +0100
                              Re: obviscating python code for distribution harrismh777 <harrismh777@charter.net> - 2011-05-20 15:24 -0500
                                Re: obviscating python code for distribution geremy condra <debatem1@gmail.com> - 2011-05-20 15:45 -0700
                                  Re: obviscating python code for distribution Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-05-21 00:54 +0000
                                    Re: obviscating python code for distribution harrismh777 <harrismh777@charter.net> - 2011-05-20 23:26 -0500
                          Re: obviscating python code for distribution Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-05-20 07:10 +0000
                            Re: obviscating python code for distribution geremy condra <debatem1@gmail.com> - 2011-05-20 09:26 -0700
                            Re: obviscating python code for distribution Nobody <nobody@nowhere.com> - 2011-05-20 18:48 +0100
                        Re: obviscating python code for distribution Chris Angelico <rosuav@gmail.com> - 2011-05-20 11:33 +1000
                        Re: obviscating python code for distribution geremy condra <debatem1@gmail.com> - 2011-05-19 19:30 -0700
                        Re: obviscating python code for distribution Chris Angelico <rosuav@gmail.com> - 2011-05-20 12:35 +1000
        Re: obviscating python code for distribution Chris Angelico <rosuav@gmail.com> - 2011-05-19 03:24 +1000
          Re: obviscating python code for distribution John Bokma <john@castleamber.com> - 2011-05-18 12:31 -0500
            Re: obviscating python code for distribution Chris Angelico <rosuav@gmail.com> - 2011-05-19 03:52 +1000
        Re: obviscating python code for distribution geremy condra <debatem1@gmail.com> - 2011-05-18 10:40 -0700
        Re: obviscating python code for distribution Chris Angelico <rosuav@gmail.com> - 2011-05-19 04:07 +1000
        Re: obviscating python code for distribution "Littlefield, Tyler" <tyler@tysdomain.com> - 2011-05-18 12:26 -0600
          Re: obviscating python code for distribution harrismh777 <harrismh777@charter.net> - 2011-05-18 21:54 -0500
            Re: obviscating python code for distribution geremy condra <debatem1@gmail.com> - 2011-05-19 10:50 -0700
              Re: obviscating python code for distribution harrismh777 <harrismh777@charter.net> - 2011-05-20 01:17 -0500
        Re: obviscating python code for distribution Dotan Cohen <dotancohen@gmail.com> - 2011-05-18 21:30 +0300
        Re: obviscating python code for distribution Dotan Cohen <dotancohen@gmail.com> - 2011-05-18 21:31 +0300
        Re: obviscating python code for distribution Chris Angelico <rosuav@gmail.com> - 2011-05-19 04:37 +1000
        Re: obviscating python code for distribution Chris Angelico <rosuav@gmail.com> - 2011-05-19 04:49 +1000
        Re: obviscating python code for distribution geremy condra <debatem1@gmail.com> - 2011-05-18 14:47 -0700

Page 1 of 3  [1] 2 3  Next page →

#5462 — Re: obviscating python code for distribution

On Mon, May 16, 2011 at 1:04 PM, Littlefield, Tyler <tyler@tysdomain.com> wrote:
> Hello all:
> Finally, is there a good way to accomplish this? I know that I can make .pyc
> files, but those can be disassembled very very easily with the disassembler
> and shipping these still means that the person needs the modules that are
> used. Is there another way to go about this?

No, there is no way to prevent users from getting access to raw python
sources. By its nature and design, python is not meant to be used this
way, and even obfuscation would not harm readability much.
However, you can write all parts you want to hide in C/C++/Cython and
distribute them as .so/.dll

-- 
With best regards,
Daniel Kluev

[toc] | [next] | [standalone]

#5536

On Mon, 16 May 2011 03:21:00 +0100, Daniel Kluev <dan.kluev@gmail.com>  
wrote:

> On Mon, May 16, 2011 at 1:04 PM, Littlefield, Tyler  
> <tyler@tysdomain.com> wrote:
>> Hello all:
>> Finally, is there a good way to accomplish this? I know that I can make  
>> .pyc
>> files, but those can be disassembled very very easily with the  
>> disassembler
>> and shipping these still means that the person needs the modules that  
>> are
>> used. Is there another way to go about this?
>
> No, there is no way to prevent users from getting access to raw python
> sources. By its nature and design, python is not meant to be used this
> way, and even obfuscation would not harm readability much.
> However, you can write all parts you want to hide in C/C++/Cython and
> distribute them as .so/.dll

...which is, of course, not exactly secure either.  A sufficiently  
determined hacker won't have much trouble disassembling a shared library  
even if you do strip out all the debug information.  By chance I'm having  
to do something closely related to this at work just at the moment; it's  
hard, but far from impossible.

-- 
Rhodri James *-* Wildebeest Herder to the Masses

[toc] | [prev] | [next] | [standalone]

#5668

On Mon, 16 May 2011 23:42:40 +0100, Rhodri James
  <rhodri@wildebst.demon.co.uk> wrote:
:  ...which is, of course, not exactly secure either.  A sufficiently  
:  determined hacker won't have much trouble disassembling a shared library  
:  even if you do strip out all the debug information.  By chance I'm having  
:  to do something closely related to this at work just at the moment; it's  
:  hard, but far from impossible.

But then, nothing is secure in any absolute sense.  The best you can
do with all your security efforts is to manage risk.  Since obfuscation
increases the cost of mounting an attack, it also reduces risk,
and thereby provides some level of security.

Obviously, if your threat sources are dedicated hackers or maybe MI5,
there is no point bothering with obfuscation, but if your threat source
is script kiddies, then it might be quite effective.

-- 
:-- Hans Georg

[toc] | [prev] | [next] | [standalone]

#5701

On Wed, May 18, 2011 at 10:36, Hans Georg Schaathun <hg@schaathun.net> wrote:
> But then, nothing is secure in any absolute sense.  The best you can
> do with all your security efforts is to manage risk.  Since obfuscation
> increases the cost of mounting an attack, it also reduces risk,
> and thereby provides some level of security.
>
> Obviously, if your threat sources are dedicated hackers or maybe MI5,
> there is no point bothering with obfuscation, but if your threat source
> is script kiddies, then it might be quite effective.
>

The flip side is that the developer will not know about weaknesses
until much later in the development, when making changes to the
underlying code organization may be difficult or impossible. In this
early phase of development, he should actually encourage the script
kiddies to "report the bugs".


-- 
Dotan Cohen

http://gibberish.co.il
http://what-is-what.com

[toc] | [prev] | [next] | [standalone]

#5708

On Wed, May 18, 2011 at 12:36 AM, Hans Georg Schaathun <hg@schaathun.net> wrote:
> On Mon, 16 May 2011 23:42:40 +0100, Rhodri James
>  <rhodri@wildebst.demon.co.uk> wrote:
> :  ...which is, of course, not exactly secure either.  A sufficiently
> :  determined hacker won't have much trouble disassembling a shared library
> :  even if you do strip out all the debug information.  By chance I'm having
> :  to do something closely related to this at work just at the moment; it's
> :  hard, but far from impossible.
>
> But then, nothing is secure in any absolute sense.

If you're talking security and not philosophy, there is such a thing
as a secure system. As a developer you should aim for it.

> The best you can
> do with all your security efforts is to manage risk.  Since obfuscation
> increases the cost of mounting an attack, it also reduces risk,
> and thereby provides some level of security.

The on-the-ground reality is that it doesn't. Lack of access to the
source code has not kept windows or adobe acrobat or flash player
secure, and they have large full-time security teams, and as you might
imagine from the amount of malware floating around targeting those
systems there are a lot of people who have these skills in spades.

> Obviously, if your threat sources are dedicated hackers or maybe MI5,
> there is no point bothering with obfuscation, but if your threat source
> is script kiddies, then it might be quite effective.

On the theory that any attack model without an adversary is
automatically secure?

Geremy Condra

[toc] | [prev] | [next] | [standalone]

#5710

On Wed, 18 May 2011 09:54:30 -0700, geremy condra
  <debatem1@gmail.com> wrote:
:  On Wed, May 18, 2011 at 12:36 AM, Hans Georg Schaathun <hg@schaathun.net> wrote:
: > But then, nothing is secure in any absolute sense.
: 
:  If you're talking security and not philosophy, there is such a thing
:  as a secure system. As a developer you should aim for it.

You think so?  Please name one, and let us know how you know that it
is secure.

: > and thereby provides some level of security.
:
:  The on-the-ground reality is that it doesn't. Lack of access to the
:  source code has not kept windows or adobe acrobat or flash player
:  secure, and they have large full-time security teams, and as you might
:  imagine from the amount of malware floating around targeting those
:  systems there are a lot of people who have these skills in spades.

You are just demonstrating that it does not provide complete security,
something which I never argued against.

: > Obviously, if your threat sources are dedicated hackers or maybe MI5,
: > there is no point bothering with obfuscation, but if your threat source
: > is script kiddies, then it might be quite effective.
: 
:  On the theory that any attack model without an adversary is
:  automatically secure?

No, on the assumption that we were discussing real systems, real
threats, and practical solutions, rather than models and theory.
There will always be adversaries, but they have limited means, and 
limited interest in your system.  And the limits vary.  Any marginal 
control will stave off a few potential attackers who just could not 
be bothered.

In theory, you can of course talk about absolute security.  For
instance, one can design something like AES¹, which is secure in
a very limited, theoretical model.  However, to be of any practical
use, AES must be built into a system, interacting with other systems,
and the theory and skills to prove that such a system be secure simply 
has not been developed.

Why do you think Common Criteria have not yet specified frameworks
for the top levels of assurance?

¹ Advanced Encryption Standard
-- 
:-- Hans Georg

[toc] | [prev] | [next] | [standalone]

#5729

On Wed, May 18, 2011 at 10:33 AM, Hans Georg Schaathun <hg@schaathun.net> wrote:
> On Wed, 18 May 2011 09:54:30 -0700, geremy condra
>  <debatem1@gmail.com> wrote:
> :  On Wed, May 18, 2011 at 12:36 AM, Hans Georg Schaathun <hg@schaathun.net> wrote:
> : > But then, nothing is secure in any absolute sense.
> :
> :  If you're talking security and not philosophy, there is such a thing
> :  as a secure system. As a developer you should aim for it.
>
> You think so?  Please name one, and let us know how you know that it
> is secure.

I was playing around with an HSM the other day that had originally
targeted FIPS 140-3 level 5, complete with formal verification models
and active side-channel countermeasures. I'm quite confident that it
was secure in nearly any practical sense.

> : > and thereby provides some level of security.
> :
> :  The on-the-ground reality is that it doesn't. Lack of access to the
> :  source code has not kept windows or adobe acrobat or flash player
> :  secure, and they have large full-time security teams, and as you might
> :  imagine from the amount of malware floating around targeting those
> :  systems there are a lot of people who have these skills in spades.
>
> You are just demonstrating that it does not provide complete security,
> something which I never argued against.

Ah, my mistake- when you said 'some level of security' I read that as
'some meaningful level of security'. If you were arguing that it
provided roughly as much protection to your code as the curtain of air
surrounding you does to your body, then yes- you're correct.

> : > Obviously, if your threat sources are dedicated hackers or maybe MI5,
> : > there is no point bothering with obfuscation, but if your threat source
> : > is script kiddies, then it might be quite effective.
> :
> :  On the theory that any attack model without an adversary is
> :  automatically secure?
>
> No, on the assumption that we were discussing real systems, real
> threats, and practical solutions, rather than models and theory.
> There will always be adversaries, but they have limited means, and
> limited interest in your system.  And the limits vary.  Any marginal
> control will stave off a few potential attackers who just could not
> be bothered.

Empirically this doesn't appear to be a successful gambit, and from an
attacker's point of view it's pretty easy to see why. When a system
I'm trying to break turns out to have done something stupid like this,
it really just ticks me off, and I know a lot of actual attackers who
think the same way.

> In theory, you can of course talk about absolute security.  For
> instance, one can design something like AES¹, which is secure in
> a very limited, theoretical model.  However, to be of any practical
> use, AES must be built into a system, interacting with other systems,
> and the theory and skills to prove that such a system be secure simply
> has not been developed.

This is flatly incorrect.

> Why do you think Common Criteria have not yet specified frameworks
> for the top levels of assurance?

Perhaps because the lower levels of 'assurance' don't seem to provide very much.

Geremy Condra

[toc] | [prev] | [next] | [standalone]

#5733

On Wed, 18 May 2011 12:07:49 -0700, geremy condra
  <debatem1@gmail.com> wrote:
:  I was playing around with an HSM the other day that had originally
:  targeted FIPS 140-3 level 5, complete with formal verification models
:  and active side-channel countermeasures. I'm quite confident that it
:  was secure in nearly any practical sense.

And you ostensibly use the word /nearly/ rather than «absolutely».
It seems that we agree.

BTW, according to the sources I can find quickly, FIPS 140-3
targets /modules/ and not systems.

:  Ah, my mistake- when you said 'some level of security' I read that as
:  'some meaningful level of security'. If you were arguing that it
:  provided roughly as much protection to your code as the curtain of air
:  surrounding you does to your body, then yes- you're correct.

Well, I didn't.  Whether it is meaningful is relative and dependent
on the context, but it sure isn't meaningful if any values at stake are.

:  Empirically this doesn't appear to be a successful gambit, and from an
:  attacker's point of view it's pretty easy to see why. When a system
:  I'm trying to break turns out to have done something stupid like this,
:  it really just ticks me off, and I know a lot of actual attackers who
:  think the same way.

That is very true.  It is a very crude measure with a marginal
effect on risk.  Going out of one's way to try to obfuscate the
code as machine code, as was the starting point of the discussion,
is surely not a good strategy, as one is then spending significant 
time to achieve a rather insignificant.

My main concern is that the use of absolutes, «you need this», and
«that is silly», is drawing attention from the main point.  Rather,
get to know your risks and focus on the greater ones.  Consider
possible controls, and choose cheap and effective ones.  Even a
marginally effective control may be worth-while if the cost is even
less.  We all seem to agree on the main point; many have argued the
same way.

As an aside, OTOH, don't you think MAYFARE would have been broken 
earlier if the source code were open?  It was around for ages before 
it was.

: > In theory, you can of course talk about absolute security.  For
: > instance, one can design something like AES¹, which is secure in
: > a very limited, theoretical model.  However, to be of any practical
: > use, AES must be built into a system, interacting with other systems,
: > and the theory and skills to prove that such a system be secure simply
: > has not been developed.
: 
:  This is flatly incorrect.

Which part of it?  If you claim that the theory and skills to prove it
exist, could you give a reference please?

Of course, if you are only thinking of «nearly any practical sense»
again, then we agree and always did.

: > Why do you think Common Criteria have not yet specified frameworks
: > for the top levels of assurance?
: 
:  Perhaps because the lower levels of 'assurance' don't seem to provide very much.

If the lower levels do not, would that not be an argument to implement
more levels?  Too many governments have put too much resources into 
this to just throw it away if the methodology to achieve higher assurance
could be codified.

Or maybe it is right to say that the theory and skills do exist, but the
money to gather it all in one project to demonstrate the security of
a single system does not :-)

-- 
:-- Hans Georg

[toc] | [prev] | [next] | [standalone]

#5744

On Wed, May 18, 2011 at 12:56 PM, Hans Georg Schaathun <hg@schaathun.net> wrote:
> On Wed, 18 May 2011 12:07:49 -0700, geremy condra
>  <debatem1@gmail.com> wrote:
> :  I was playing around with an HSM the other day that had originally
> :  targeted FIPS 140-3 level 5, complete with formal verification models
> :  and active side-channel countermeasures. I'm quite confident that it
> :  was secure in nearly any practical sense.
>
> And you ostensibly use the word /nearly/ rather than «absolutely».
> It seems that we agree.

Systems can be designed that are absolutely secure under reasonable
assumptions. The fact that it has assumptions does not make your
statement true.

> BTW, according to the sources I can find quickly, FIPS 140-3
> targets /modules/ and not systems.

I can't tell if you're trying to play word games with the distinction
between "system" and "module" or if you're just saying that you aren't
sure what FIPS actually certifies. Could you please clarify?

> :  Ah, my mistake- when you said 'some level of security' I read that as
> :  'some meaningful level of security'. If you were arguing that it
> :  provided roughly as much protection to your code as the curtain of air
> :  surrounding you does to your body, then yes- you're correct.
>
> Well, I didn't.  Whether it is meaningful is relative and dependent
> on the context, but it sure isn't meaningful if any values at stake are.

Again, I'm unsure what you're going for here. It sounds like you're
saying that obfuscation doesn't provide meaningful security, which is
my point.

> :  Empirically this doesn't appear to be a successful gambit, and from an
> :  attacker's point of view it's pretty easy to see why. When a system
> :  I'm trying to break turns out to have done something stupid like this,
> :  it really just ticks me off, and I know a lot of actual attackers who
> :  think the same way.
>
> That is very true.  It is a very crude measure with a marginal
> effect on risk.  Going out of one's way to try to obfuscate the
> code as machine code, as was the starting point of the discussion,
> is surely not a good strategy, as one is then spending significant
> time to achieve a rather insignificant.
>
> My main concern is that the use of absolutes, «you need this», and
> «that is silly», is drawing attention from the main point.  Rather,
> get to know your risks and focus on the greater ones.  Consider
> possible controls, and choose cheap and effective ones.  Even a
> marginally effective control may be worth-while if the cost is even
> less.  We all seem to agree on the main point; many have argued the
> same way.
>
> As an aside, OTOH, don't you think MAYFARE would have been broken
> earlier if the source code were open?  It was around for ages before
> it was.

Are you talking about the Mayfair classical cipher here?

> : > In theory, you can of course talk about absolute security.  For
> : > instance, one can design something like AES¹, which is secure in
> : > a very limited, theoretical model.  However, to be of any practical
> : > use, AES must be built into a system, interacting with other systems,
> : > and the theory and skills to prove that such a system be secure simply
> : > has not been developed.
> :
> :  This is flatly incorrect.
>
> Which part of it?  If you claim that the theory and skills to prove it
> exist, could you give a reference please?

The entire field of formal modeling and verification has grown around
solving this problem. My new favorite in the field is "formal models
and techniques for analyzing security protocols", but there are other
works discussing OS kernel verification (which has gotten a lot of
attention lately) and tons of academic literature. Google (scholar) is
the place to go.

> Of course, if you are only thinking of «nearly any practical sense»
> again, then we agree and always did.

Nope, talking about formal methods.

> : > Why do you think Common Criteria have not yet specified frameworks
> : > for the top levels of assurance?
> :
> :  Perhaps because the lower levels of 'assurance' don't seem to provide very much.
>
> If the lower levels do not, would that not be an argument to implement
> more levels?  Too many governments have put too much resources into
> this to just throw it away if the methodology to achieve higher assurance
> could be codified.

If you can't say with confidence that something meets minimum security
standards, the answer is not to try to say it meets high security
standards.

> Or maybe it is right to say that the theory and skills do exist, but the
> money to gather it all in one project to demonstrate the security of
> a single system does not :-)

Sorry, but again this is not correct.

Geremy Condra

[toc] | [prev] | [next] | [standalone]

#5762

On Wed, 18 May 2011 14:34:46 -0700, geremy condra
  <debatem1@gmail.com> wrote:
:  Systems can be designed that are absolutely secure under reasonable
:  assumptions. The fact that it has assumptions does not make your
:  statement true.
: (...)
:  I can't tell if you're trying to play word games with the distinction
:  between "system" and "module" or if you're just saying that you aren't
:  sure what FIPS actually certifies. Could you please clarify?

The distinction between system and module is rather significant.
If you only consider modules, you have bounded your problem and
drastically limited the complexity.

:  Again, I'm unsure what you're going for here. It sounds like you're
:  saying that obfuscation doesn't provide meaningful security, which is
:  my point.

Meaningful is a relative term, and it is hard to rule out the 
possibility that meaning can be found in some case.  Overall, we
agree though.

:  Are you talking about the Mayfair classical cipher here?

I am talking about the system used in public transport cards like
Oyster and Octopus.  I am not sure how classical it is, or whether
mayfair/mayfare referred to the system or just a cipher.  Any way,
it was broken, and it took years.

:  The entire field of formal modeling and verification has grown around
:  solving this problem. My new favorite in the field is "formal models
:  and techniques for analyzing security protocols", but there are other
:  works discussing OS kernel verification (which has gotten a lot of
:  attention lately) and tons of academic literature. Google (scholar) is
:  the place to go.

Sure, but now you are considering modules, rather than systems again.
It is when these reliable components are put together to form systems
that people fail (empirically).

:  If you can't say with confidence that something meets minimum security
:  standards, the answer is not to try to say it meets high security
:  standards.

So what?  The levels of assurance have nothing to do with standards.
The levels of assurance refer to the /confidence/ you can have that
the standards are met.

: > Or maybe it is right to say that the theory and skills do exist, but the
: > money to gather it all in one project to demonstrate the security of
: > a single system does not :-)
: 
:  Sorry, but again this is not correct.

You keep saying that, but whenever you try to back the claim, you 
keep referring to limited components and not systems at all.

-- 
:-- Hans Georg

[toc] | [prev] | [next] | [standalone]

#5765

On Thu, 19 May 2011 06:21:08 +0100, Hans Georg Schaathun wrote:

> :  Are you talking about the Mayfair classical cipher here?
> 
> I am talking about the system used in public transport cards like Oyster
> and Octopus.  I am not sure how classical it is, or whether
> mayfair/mayfare referred to the system or just a cipher.  


I think Geremy is talking about the Playfair cipher:

http://en.wikipedia.org/wiki/Playfair_cipher


> Any way, it was broken, and it took years.

You don't know that. All you know is that it took years for people to 
realise that it had been broken, when a security researcher publicly 
announced the MIFARE cipher had been broken. If criminals had broken the 
cipher, they would have had no incentive to publicize the fact, and the 
companies running Oyster and similar ticketing schemes would have no 
incentive to admit they were broken. Far from it: all the incentives are 
against disclosure.

So it's possible that Oyster cards have been counterfeited for years 
without anyone but the counterfitters, and possibly the Oyster card 
people themselves, knowing.

The real barrier to cracking Oyster cards is not that the source code is 
unavailable, but that the intersection of the set of those who know how
to break encryption, and the set of those who want to break Oyster cards, 
is relatively small. I don't know how long it took to break the encryption, 
but I'd guess that it was probably a few days of effort by somebody 
skilled in the art.

http://www.usenix.org/events/sec08/tech/full_papers/nohl/nohl_html/index.html




-- 
Steven

[toc] | [prev] | [next] | [standalone]

#5767

On 19 May 2011 08:47:28 GMT, Steven D'Aprano
  <steve+comp.lang.python@pearwood.info> wrote:
:  The real barrier to cracking Oyster cards is not that the source code is 
:  unavailable, but that the intersection of the set of those who know how
:  to break encryption, and the set of those who want to break Oyster cards, 
:  is relatively small. I don't know how long it took to break the encryption, 
:  but I'd guess that it was probably a few days of effort by somebody 
:  skilled in the art.
: 
:  http://www.usenix.org/events/sec08/tech/full_papers/nohl/nohl_html/index.html

In that paper, more than one art seem to have been applied.  An open 
design would have eliminated the need for image analysis and reduced
the requirement on hardware/electronics skills.  Hence, the obfuscation
has made that intersection you talk about smaller, and increased the
cost of mounting the attack.  As the system was broken anyway, it is
hardly a victory for obfuscation, but that's beside the point.

The work of that paper is almost certainly more than just «a few
days of effort».  There are simply to many technical issues to tackle,
and they must be tackled one by one.  The cost of mounting the attack
is to figure out what it takes to do it, before spend the resources
barking up the wrong tree.  For each successful attack, there probably
is a number of failed ones.

Thanks for the reference.

BTW.  That's not the only attack on MIFARE.  I cannot remember the
details of the other.

-- 
:-- Hans Georg

[toc] | [prev] | [next] | [standalone]

#5779

On Wed, May 18, 2011 at 10:21 PM, Hans Georg Schaathun <hg@schaathun.net> wrote:
> On Wed, 18 May 2011 14:34:46 -0700, geremy condra
>  <debatem1@gmail.com> wrote:
> :  Systems can be designed that are absolutely secure under reasonable
> :  assumptions. The fact that it has assumptions does not make your
> :  statement true.
> : (...)
> :  I can't tell if you're trying to play word games with the distinction
> :  between "system" and "module" or if you're just saying that you aren't
> :  sure what FIPS actually certifies. Could you please clarify?
>
> The distinction between system and module is rather significant.
> If you only consider modules, you have bounded your problem and
> drastically limited the complexity.

Ah, the 'word games' option. I'm not going to spend a lot of time
arguing this one: HSMs are clearly the domain of systems research, are
referred to in both technical and nontechnical documents as 'keystone
systems', and the FIPS standard under which they are certified
specifically calls them systems more times than I care to count. They
are, to the people who make and use them, systems, and your attempt at
redefinition won't change that.

> :  Are you talking about the Mayfair classical cipher here?
>
> I am talking about the system used in public transport cards like
> Oyster and Octopus.  I am not sure how classical it is, or whether
> mayfair/mayfare referred to the system or just a cipher.  Any way,
> it was broken, and it took years.

Ah, MIFARE. That's a different story, and no, I don't believe they
would have been broken sooner if the specs were released. The
importance (and difficulty) of securing devices like smartcards wasn't
really recognized until much later, and certainly people with a foot
in both worlds were very rare for a long time. Also remember that DES
(with its 56-bit keys) was recertified just a few months before MIFARE
(with its 48-bit keys) was first released- it was a different world.

> :  The entire field of formal modeling and verification has grown around
> :  solving this problem. My new favorite in the field is "formal models
> :  and techniques for analyzing security protocols", but there are other
> :  works discussing OS kernel verification (which has gotten a lot of
> :  attention lately) and tons of academic literature. Google (scholar) is
> :  the place to go.
>
> Sure, but now you are considering modules, rather than systems again.
> It is when these reliable components are put together to form systems
> that people fail (empirically).

Let me get this straight: your argument is that operating *systems*
aren't systems?

> :  If you can't say with confidence that something meets minimum security
> :  standards, the answer is not to try to say it meets high security
> :  standards.
>
> So what?  The levels of assurance have nothing to do with standards.
> The levels of assurance refer to the /confidence/ you can have that
> the standards are met.

The increasing levels of assurance don't just signify that you've
checked for problems- it certifies that you don't have them, at least
insofar as that level of testing is able to find. Insisting that this
doesn't, or shouldn't, translate into tighter security doesn't make
much sense.

Geremy Condra

[toc] | [prev] | [next] | [standalone]

#5781

On Thu, 19 May 2011 10:23:47 -0700, geremy condra
  <debatem1@gmail.com> wrote:
:  Let me get this straight: your argument is that operating *systems*
:  aren't systems?

You referred to the kernel and not the system.  The complexities of
the two are hardly comparable.

There probably are different uses of system; in computer security
literature¹ it often refers, not only to a product (hardware/software)
an actual installation and configuration of that product in a specific
context.  /I/ did not redefine it.

Speaking of reasonable assumptions, one necessary assumption which is
particularly dodgy is that whoever deploys and configures it
understands all the assumptions and do not break them through ignorance.

Is your concern with security purely from a developer's viewpoint,
so that you don't have to worry about the context in which it will
be deployed?

: > So what?  The levels of assurance have nothing to do with standards.
: > The levels of assurance refer to the /confidence/ you can have that
: > the standards are met.
: 
:  The increasing levels of assurance don't just signify that you've
:  checked for problems- it certifies that you don't have them, at least
:  insofar as that level of testing is able to find. Insisting that this
:  doesn't, or shouldn't, translate into tighter security doesn't make
:  much sense.

Tighter sure, but the security requirements and the requirement on
testing and/or validation are orthogonal scales.  The higher levels
of assurance are based on formal methods while the lower ones are based
primarily on testing.  

I read your initial comment to imply that if you cannot get satisfactory
assurance using the lower levels, you won't get any at the higher
levels.  That does not make any sense.  Obviously, if you were implying
that no system passes the lower levels, then of course they won't pass
the higher levels, but then, if that's the case, we would all know that
we cannot even design /seemingly/ secure systems.  And nobody has
suggested that so far.


¹ e.g. Dieter Gollmann for just one ref off the top of my head.
-- 
:-- Hans Georg

[toc] | [prev] | [next] | [standalone]

#5801

On Thu, May 19, 2011 at 11:23 AM, Hans Georg Schaathun <hg@schaathun.net> wrote:
> On Thu, 19 May 2011 10:23:47 -0700, geremy condra
>  <debatem1@gmail.com> wrote:
> :  Let me get this straight: your argument is that operating *systems*
> :  aren't systems?
>
> You referred to the kernel and not the system.  The complexities of
> the two are hardly comparable.

I don't know about that. Among the many verified microkernels, at
least two projects have formally verified both their kernel and their
toolchain, and one of them claims they've verified everything in their
TCB and are headed towards verified POSIX compliance in 2012. That
would seem to be a fairly large system (and definitely a complete OS)
to me. Another (seL4) says they've formally verified security  of a
complete system that includes a userspace and the ability to run other
OSes in fully isolated containers, which also seems to be quite
complete. Finally, there's one from Microsoft research that claims
similar properties but which apparently isn't interested in
compatibility, which I'm not sure how to interpret in terms of
usefulness and size. In any event, higher level systems- like
electronic voting mechanisms and automotive sensor networks- have also
been verified, which seems to run counter to your original point.

Also, not sure if it's open to the general public but if you're
interested in this kind of thing and live near seattle, I think
there's actually going to be a talk on verifying a POSIX userspace
implementation here tomorrow.

TL;DR version: large systems have indeed been verified for their
security properties.

> There probably are different uses of system; in computer security
> literature¹ it often refers, not only to a product (hardware/software)
> an actual installation and configuration of that product in a specific
> context.  /I/ did not redefine it.

You chose a word with a many meanings, used it to make a very broad
statement which is only a little bit true, and then pretended that you
had the One True Definition in your pocket. I don't think that's
legitimate, but whatever; let's just say that we meant different
things by the word and drop it.

> Speaking of reasonable assumptions, one necessary assumption which is
> particularly dodgy is that whoever deploys and configures it
> understands all the assumptions and do not break them through ignorance.

Yup. Nothing is safe from idiots.

> Is your concern with security purely from a developer's viewpoint,
> so that you don't have to worry about the context in which it will
> be deployed?

My viewpoint is that of an attacker, since that's more or less my job.

> I read your initial comment to imply that if you cannot get satisfactory
> assurance using the lower levels, you won't get any at the higher
> levels.  That does not make any sense.

Well, this is kind of like my point. My point was that you really
don't get anything at the lower levels, and that they should fix that
(which is far more useful to a normal consumer) rather than trying to
talk about formal verification and similar tools, which are only going
to be used on a tiny fraction of products.

Geremy Condra

[toc] | [prev] | [next] | [standalone]

#5810

On Thu, 19 May 2011 17:56:12 -0700, geremy condra
  <debatem1@gmail.com> wrote:
:  TL;DR version: large systems have indeed been verified for their
:  security properties.
: (...)
:  Yup. Nothing is safe from idiots.

The difficult part is mapping those properties to actual requirements
and threat models.  Formal methods do not help on that step.  It takes
more than a non-idiot to avoid misunderstandings on the interface 
betweeen professions.

Either way, the assumption that your system will not be handled by
idiots is only reasonable if you yourself is the only user.

-- 
:-- Hans Georg

[toc] | [prev] | [next] | [standalone]

#5828

On Fri, 20 May 2011 05:48:50 +0100, Hans Georg Schaathun wrote:

> Either way, the assumption that your system will not be handled by
> idiots is only reasonable if you yourself is the only user.

Nonsense. How do you (generic "you", not any specific person) know that 
you are not an idiot?

If you are an idiot, you obviously shouldn't trust your own judgment -- 
although of course idiots do trust their own judgment when they 
shouldn't, and the less they know, the less they realise how little they 
know:

http://en.wikipedia.org/wiki/Dunning–Kruger_effect

So if you think that you're not an idiot, you might be an idiot who is 
unaware of being an idiot. Your own opinion is the last opinion you 
should pay attention to. The world is full of people with delusions of 
superiority -- only an idiot would trust their own opinion of themselves.

You can listen to others, but only so long as you don't surround yourself 
with idiots. But how do you know if the people around you are idiots? You 
certainly can't trust your judgment, nor can you trust theirs. If you're 
an idiot, you (still talking about generic "you") and your idiot friends 
are probably all congratulating yourselves for not being idiots.

In contrast, if you're not an idiot, then you probably are aware (and if 
not, you should be) of all the cognitive biases human beings are prone 
to, of all the mental and emotional weaknesses that we all suffer from, 
which cause us to act in idiotic ways. If you're not an idiot, then you 
know your limitations, that like everyone, you can be fooled or foolish, 
that you can make mistakes, that you sometimes operate equipment when you 
are not at the optimum level of alertness, when your attention to detail 
is below normal or you are a little more careless than you should be.

In short, that everyone, including yourself, can be an idiot, and the 
more intelligent you are, the more astonishingly stupid your mistakes may 
be. Any moron can accidentally burn themselves with a match, but it takes 
a first-class genius to give chronic lead poisoning to tens of millions 
*and* nearly destroy the ozone layer of the entire world:

http://en.wikipedia.org/wiki/Thomas_Midgley,_Jr.

So... if you think you are not an idiot, you are, and if you think you 
are an idiot, you are. Either way, even if your software is only being 
used by yourself, you should still attempt to make it as idiot-proof as 
an idiot like yourself can make it.



-- 
Steven

[toc] | [prev] | [next] | [standalone]

#5841

On 20 May 2011 07:04:27 GMT, Steven D'Aprano
  <steve+comp.lang.python@pearwood.info> wrote:
:  On Fri, 20 May 2011 05:48:50 +0100, Hans Georg Schaathun wrote:
: 
: > Either way, the assumption that your system will not be handled by
: > idiots is only reasonable if you yourself is the only user.
: 
:  Nonsense. How do you (generic "you", not any specific person) know that 
:  you are not an idiot?

You don't, but if you are, you cannot trust any of the other assumptions
either, and making this assumption is reasonable by being less of a leap
than anything else you have done.

-- 
:-- Hans Georg

[toc] | [prev] | [next] | [standalone]

#5880

Steven D'Aprano wrote:
> Nonsense. How do you (generic "you", not any specific person) know that
> you are not an idiot?

lol     Sum, ergo Idiot cogitat.


Reminds me of a philosophical story I heard one time from my religion 
professor...

... as it goes, De Carte leads his horse into town   ;-)  and having 
hitched it to the rail outside the local saloon and sauntering up to the 
bar,  the tender asks, "Would you be hav'in an ale sir?"

... De Carte replies, "I think not..."     ... and then disappeared.


:)

[toc] | [prev] | [next] | [standalone]

#5887

On Fri, May 20, 2011 at 1:24 PM, harrismh777 <harrismh777@charter.net> wrote:
> Steven D'Aprano wrote:
>>
>> Nonsense. How do you (generic "you", not any specific person) know that
>> you are not an idiot?
>
> lol     Sum, ergo Idiot cogitat.
>
>
> Reminds me of a philosophical story I heard one time from my religion
> professor...
>
> ... as it goes, De Carte leads his horse into town   ;-)  and having hitched
> it to the rail outside the local saloon and sauntering up to the bar,  the
> tender asks, "Would you be hav'in an ale sir?"
>
> ... De Carte replies, "I think not..."     ... and then disappeared.

At risk of being pedantic, I think you mean Descartes rather than De Carte.

Geremy Condra

[toc] | [prev] | [next] | [standalone]

Page 1 of 3  [1] 2 3  Next page →

Back to top | Article view | comp.lang.python

csiph-web