Security App for Android - which checksum to use?

Hey developers and beloved openSUSE-Geeks,

please don’t start a fight when I post some information about my own project now: I would like you to help me out with a relative simple answer: My team and myself are currently developing on an important security project on GitHub called “Android IMSI-Catcher Detector”, which started out on our XDA-Developers Thread. To ensure downloaded WIP-Releases from GitHub are corrently downloaded or tampered with, I’m currently thinking about the** most secure checksum** for the APKs.

Question: Would you still recommend to use SHA-1, or shall I use some other checksum? I know, I could just use MD5 checksums, but since this is a security related project, I am taking even this fairly simple task very serious and thought I’d just ask my favourite openSUSE geeks first. So hit me, am open for suggestions!

Thank you for every friendly answer.

SecUpwN

On 2014-05-25 20:46, SecUpwN wrote:

> Question: Would you still recommend to use SHA-1, or shall I use some
> other checksum? I know, I could just use MD5 checksums, but since this
> is a security related project, I am taking even this fairly simple task
> very serious and thought I’d just ask my favourite openSUSE geeks first.
> So hit me, am open for suggestions!

Well, you know that openSUSE uses gpg verification for the downloaded
packages.


Cheers / Saludos,

Carlos E. R.
(from 13.1 x86_64 “Bottle” at Telcontar)

On Sun, 25 May 2014 18:46:01 +0000, SecUpwN wrote:

> most secure checksum*

This is something of a misnomer - checksums aren’t “secure” or “insecure”

  • they’re checksums. One-way hashes.

If you want to provide a means of secure validation, you should sign the
apk instead.

Jim


Jim Henderson
openSUSE Forums Administrator
Forum Use Terms & Conditions at http://tinyurl.com/openSUSE-T-C

Yes. But that is not primarily what I meant. I am just searching for a tamperproof checksum of my files.

Yes, I know that. Probably expressed my intention a little unlucky. Do you still recommend SHA-1?

We’re thinking about it. Thanks.

On 2014-05-26 06:06, SecUpwN wrote:
>
> robin_listas;2645427 Wrote:
>> Well, you know that openSUSE uses gpg verification for the downloaded
>> packages.
> Yes. But that is not primarily what I meant. I am just searching for a
> tamperproof checksum of my files.

Well, pgp does that. As long as you can ensure that the certificates
have not been tampered with (which IMHO, /you/ can not), you can ensure
that your package has not been tampered with, accidentally or intentionally.

The certificates themselves (the keys) can not be safe, because the
administrator can be fooled to install rogue certificates in several
ways. If you can ensure a fools-way to distribute the certificates, then
you are safe. It is the state of the art in the opensource camp, I
understand.

Another method is with certificate authorities, which was considered
safer - but these have also been perverted (Heartbleed, rogue
authorities and certificates, etc).


Cheers / Saludos,

Carlos E. R.
(from 13.1 x86_64 “Bottle” at Telcontar)

On Mon, 26 May 2014 04:06:01 +0000, SecUpwN wrote:

> hendersj;2645460 Wrote:
>>
>> This is something of a misnomer - checksums aren’t “secure” or
>> “insecure”
>> - they’re checksums. One-way hashes.
>
> Yes, I know that. Probably expressed my intention a little unlucky. Do
> you still recommend SHA-1?

Sure, why not? Personally, I find MD5 to be just as good.

MD5 may be more prone to having hash collisions (because it’s a smaller
‘namespace’), but the odds of someone being able to your apk file,
getting something that still executes with a specific desired ‘hack’ AND
having the hash match regardless of the hash algorithm are so remote that
I wouldn’t worry about it.

Think about it. When you make a single code change and recompile your
APK, you don’t get the same hash value. If you wanted to get the same
hash value, what do you think you’d have to do? How would you go about
making your change to the code - code you know intimately - without
changing the hash the compiled and packaged output produces?

Answer: As near to nothing as makes no odds.

Jim

Jim Henderson
openSUSE Forums Administrator
Forum Use Terms & Conditions at http://tinyurl.com/openSUSE-T-C

On 2014-05-26 19:07, Jim Henderson wrote:

> Think about it. When you make a single code change and recompile your
> APK, you don’t get the same hash value. If you wanted to get the same
> hash value, what do you think you’d have to do? How would you go about
> making your change to the code - code you know intimately - without
> changing the hash the compiled and packaged output produces?

Theoretically, start changing bytes around till the checksum is again
the same one. For this to work, you need to be able to change enough
bytes in the file, which may be simply not possible because you can not
change randomly bytes in a program and still expect it to perform at
least apparently correctly. It would be somewhat easier if the file
contained sections (data?) that could be changed at will without
damaging the code. A mathematician with deep knowledge of the checksum
algorithm could perhaps optimize some code for that kind of brute force
attack.

As you say: “As near to nothing as makes no odds” :slight_smile:

(I believe there is a formula somewhere that would say how many
combinations would produce the same checksum, but not, AFAIK, which are
those combinations)


Cheers / Saludos,

Carlos E. R.
(from 13.1 x86_64 “Bottle” at Telcontar)

On Mon, 26 May 2014 18:28:06 +0000, Carlos E. R. wrote:

> On 2014-05-26 19:07, Jim Henderson wrote:
>
>> Think about it. When you make a single code change and recompile your
>> APK, you don’t get the same hash value. If you wanted to get the same
>> hash value, what do you think you’d have to do? How would you go about
>> making your change to the code - code you know intimately - without
>> changing the hash the compiled and packaged output produces?
>
> Theoretically, start changing bytes around till the checksum is again
> the same one. For this to work, you need to be able to change enough
> bytes in the file, which may be simply not possible because you can not
> change randomly bytes in a program and still expect it to perform at
> least apparently correctly. It would be somewhat easier if the file
> contained sections (data?) that could be changed at will without
> damaging the code. A mathematician with deep knowledge of the checksum
> algorithm could perhaps optimize some code for that kind of brute force
> attack.

Just changing bytes isn’t enough. They have to change in such a way as
to not appear to modify the operation of the program while actually
modifying the operation of the program.

Which is a virtual impossibility - so unless you have an infinite
improbability generator and a really hot cup of tea, you’re not going to
achieve that goal. :slight_smile:

But if secure validation is what OP wants, then a checksum is the wrong
tool, as we’ve both said. Digital signing is a better option.

Jim

Jim Henderson
openSUSE Forums Administrator
Forum Use Terms & Conditions at http://tinyurl.com/openSUSE-T-C

Thank you for all your friendly answers, this clarified a lot to me. SHA-1 seems to work perfectly for now, I added checksums.
And if anybody is willing to contribute to our Android IMSI-Catcher Detector - developers and testers are always very welcome! :wink:

Thank you for this awesome community - you are THE BEST!

SecUpwN

On Tue, 27 May 2014 12:26:02 +0000, SecUpwN wrote:

> Thank you for all your friendly answers, this clarified a lot to me.
> SHA-1 seems to work perfectly for now, I added checksums.
> And if anybody is willing to contribute to our ‘Android IMSI-Catcher
> Detector’ (https://github.com/SecUpwN/Android-IMSI-Catcher-Detector) -
> developers and testers are always very welcome! :wink:
>
> Thank you for this awesome community - you are THE BEST!

Glad we could help out. And you’ve given me an idea for a question to
Randall Munroe (of XKCD and his weekly blog “What if?”) that I’m probably
going to submit in the near future. :wink:

Jim


Jim Henderson
openSUSE Forums Administrator
Forum Use Terms & Conditions at http://tinyurl.com/openSUSE-T-C

On 2014-05-26 21:14, Jim Henderson wrote:
> On Mon, 26 May 2014 18:28:06 +0000, Carlos E. R. wrote:

> Just changing bytes isn’t enough. They have to change in such a way as
> to not appear to modify the operation of the program while actually
> modifying the operation of the program.

Which is why I said to modify a data section, not a code section :wink:
That is, modifying irrelevant bytes.
Next to impossible to do, in real life.

An anecdote.

I remember, long time ago, a friend of mine was studying fortran. He was
surprised that his small program would create so much code as to almost
not fit into the floppy he was working with. I found out that the empty
data array he declared was created as a BIG region of zeroes in the
executable file! The compiler did not create those variables at run time.

Well, the point here is that, depending on the code (my friend had to
fill up the array, anyway, the zeroes were irrelevant), that array could
contain anything else instead of the zeroes in the file without changing
the code behaviour at all. That is, it could be a target for this
“theoretical attack”.

> Which is a virtual impossibility - so unless you have an infinite
> improbability generator and a really hot cup of tea, you’re not going to
> achieve that goal. :slight_smile:

No - but I have the feeling that there are dark places where they have
studied this in depth.

> But if secure validation is what OP wants, then a checksum is the wrong
> tool, as we’ve both said. Digital signing is a better option.

Right!


Cheers / Saludos,

Carlos E. R.
(from 13.1 x86_64 “Bottle” at Telcontar)

On Wed, 28 May 2014 04:03:06 +0000, Carlos E. R. wrote:

>> Just changing bytes isn’t enough. They have to change in such a way as
>> to not appear to modify the operation of the program while actually
>> modifying the operation of the program.
>
> Which is why I said to modify a data section, not a code section :wink:
> That is, modifying irrelevant bytes.
> Next to impossible to do, in real life.

Both of them would be nearly impossible to do IRL.

But to make a meaningful change, it would probably have to be code that
was changed, not just data.

Jim


Jim Henderson
openSUSE Forums Administrator
Forum Use Terms & Conditions at http://tinyurl.com/openSUSE-T-C

On 2014-05-28 18:53, Jim Henderson wrote:
> On Wed, 28 May 2014 04:03:06 +0000, Carlos E. R. wrote:

> But to make a meaningful change, it would probably have to be code that
> was changed, not just data.

Yes, of course. You change the code you need, then change the data to
compensate and get the same overall checksum.

Of course, it is just “tin foil hat” speculation. If anybody can manage
to do such a thing, he has not published it, to my knowledge.


Cheers / Saludos,

Carlos E. R.
(from 13.1 x86_64 “Bottle” at Telcontar)

As others have described,
If you distribute an installation package, it should be signed. For the reasons described here in this thread, checksums are considered inadequate, they only verify the overall integrity of the package for random corruption, it’s not really meant to be a <security> solution. Signing not only implements better protections against tampering, it also provides a way to <authenticate> the file, essentially that the file has not been changed since a recognized and valid packager put the file together.

Packages are built only to ease installation.

Especially when you are developing, packaging can slow down your development because usually unless you’re implementing something like JenkinsCI, you won’t be able to create packages often on demand, your packages instead will be associated with set milestones.

During early development, you may find it’s more suitable to simply provide source and instructions how to compile and install.

TSU