Lpc2000

Robert,

Boundary scan *is* implemented according to section 22.3 of the user
manual for LPC214x parts.

"The scan chains that are around the core for production test are
reused in the debug state to capture information from the data bus and
to insert new information into the core or the memory."

Disabling debug by actively executing instruction simply disables the
reuse of these scan chains for debugging purposes through ETM.

The chains are however accessible long before the processor comes out
of reset, and software security on LPC series is only as safe as how
safely boundary scan specifications can be kept secret.

Leaving boundary scaning methods aside, there are other methods of
stalling the processor using ETM before it reaches third instruction,
for example by manually clocking as it the processor out of reset.

Reducing the window of opportunity by disabling debug port quickly
serves only increases the effort it takes to sneak in.  It does not
prevent it.

I would urge anyone who depends on code in the CEP enabled device
being secure from preying eyes to seriosly look at issues as a whole,
especially informatino that is not disclosed in the LPC scheme where
CEP is dependent on execution of instructions in the boot loader after
the procesor comes out of reset.

Jaya

--- In lpc2000@yahoogroups.com, "philips_apps" <philips_apps@y...> wrote:
>
> Boundary Scan is not just a technique, it needs to be implemented in 
> hardware as such AND IT IS NOT IMPLEMENTED on the devices on the 
> market so far.
> 
> Robert
> 
> --- In lpc2000@yahoogroups.com, "jayasooriah" <jayasooriah@y...> wrote:
> >
> > There is a technique called JTAG boundary scanning.  From memory, (I
> > did this some years ago) boundary scanning does not require the 
> target
> > to come out of reset.  In such a system, the "ememy" is all over the
> > code long before the processor even wakes up, and thus how quickly it
> > takes to secure flash becomes irrelevant.
>