Re: PG in cash till machines

Hi Carlos,

On 5/10/2013 6:43 AM, Carlos Henrique Reimer wrote:
> We are developing a solution which will run in thousands of small cash till
> machines running Linux and we would like to use PostgreSQL but there is a
> insecurity feeling regarding the solution basically because these boxes
> would be exposed to an insecure environment and insecure procedures like:
> non controlled power outages, untrusted hardware, no appropriate
> environment for hardware (dusty, hot) etc...

Welcome to my world! :>

To clarify your requirements:
- the devices contain hard currency which they either *accept* from
the user, dispense *to* the user, or both.
- the contents of the DB are critical to the proper operation
of the device (e.g., perhaps they maintain "account balances"
that, if corruptible, represent an exploit)
- presumably, the environment is secure enough that an adversary
can't just remove the entire device to abscound with the monies therein
(i.e., while it may not be "as secure as a bank lobby", neither is it
sitting in the middle of an open field! Perhaps sitting *in* a
storefront establishment?)
- the device has some physical safeguards to prevent an adversary
vandalizing it GIVEN THE LEVEL OF SUPERVISION IN ITS ENVIRONMENT
(e.g., the coinbox of a US "pay phone" is pretty hard to break into)
- yet, a subtle, clever hacker could "tease" the device into a
state that is more "generous" to his wishes (e.g., a high voltage
discharge at a key point along the case/wiring to crash the processor
at a critical point in it's transaction processing)
- a single device may not be a significant "value" target -- but,
an exploit that can be reapplied to *each* target (possibly
repeatedly, over time) makes this a sufficiently large honey pot
- you're very confident in the robustness of the underlying
OS, application and PostgreSQL itself that you don't fear problems
from any of those in "normal operation" (e.g., the kernel isn't
likely to panic due to some unforseen out-of-memory condition -- nor
the processor hiccup from operating in an overtemperature condition)

> Our major concern is related to the write-back issues we can face in this
> environment. Is there a way to prevent it or a way PG can be configured to
> detect write-back configurations? Don't think so, but...

I'm not sure what specific threat you are anticipating, here.
Could you posit a potential attack scenario against which you
would like to defend?

> Basically, the question is: is there a way to guaranty a reliable PG
> database in an untrusted and insecure environment? Maybe some kind of file
> system could give this guaranty, not sure..

Absent *physical* security, you can't do *anything*! (especially
given your reliance on FOSS components!). E.g., an adversary can
disembowel the device and massage the contents of the raw media,
etc.)

Having designed (regulated) gaming and "grey area" devices (each
handling hard currency), I can tell you that you have to have already
performed a pretty exhaustive threat analysis (e.g., red team, blue\
team) *before* you start the product's design. If you can't imagine
*all* of the ways you can be targeted, then you can't determine
how/if you will be "secure" in each of those scenarios (e.g.,
I've incorporated features into the hardware designs to counter
certain types of physical attacks).

Always consider how you can design the system to *screw* the
attacker instead of *reward* him, given the option. E.g.,
given the (fictitious) example of allowing the user to
"withdraw" funds from his "account" (possibly), then opt
for:
decrease_balance(amount)
dispense_currency(amount)
instead of:
dispense_currency(amount)
decrease_balance(amount)
as the latter case could allow an attacker to interrupt the
atomic operation *after* receiving his "hard currency" yet
before a record of this has been made. In the former case,
an attack results in his account *losing* money without ever
receiving the hard currency!

Attackers are shy about complaining that "the machine cheated
me as that brings attention to their activities! ("Oh? Let's
review the video surveillance to see what happened..." :>)

Of course, the above *should* be atomic but you can't roll-back
a *physical* transaction (i.e., reach out and grab the currency
*from* him if the transaction is aborted).

Perhaps if you can highlight specific actions that you imagine
as being vulnerabilities, a compromise solution might be
available?

[BTW, I find these the most delightful projects as you *really*
have to think outside the box -- unlike a desktop/server environment
where all you have to worry about is a disk crash, DoS attack, etc.]

G'luck!
--don