Searching \ for '[PIC] Using USB + shield for ICSP programming' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/microchip/devprogs.htm?key=programming
Search entire site for: 'Using USB + shield for ICSP programming'.

Exact match. Not showing close matches.
PICList Thread
'[PIC] Using USB + shield for ICSP programming'
2010\02\10@213152 by Johansson

flavicon
face
Dear piclist,

I am developing a USB product. For different logistics reasons, I'd like to
program the PIC18F13K50 in-circuit, after the housing is assembled. To do
that, I could add a special ICSP connector, but to keep costs low and the
housing neat, I'd like to have the existing USB connector double as the ICSP
connector, if possible. However, as "Single-Supply In Circuit Programming"
(formerly known as Low-Voltage ICSP programming) needs 5 pins, the USB plug
is one pin short. So my idea was to use the USB shield as the PGM pin.
According to the USB spec, the shield should not be connected anyway. Of
course, the ICSP adapter used to program the firmware into my device, would
have to be custom made, and even violate the USB standard. But what do you
guys think, would it work? During normal execution, is it a problem that the
shield is connected to the PGM pin?

Summary of connections:
PIC VPP - not needed for ss-ICSP
PIC VDD - wired to VBUS of USB plug
PIC GND - wired to GND of USB plug
PIC PGD - wired to D+ of USB plug
PIC PGC - wired to D- of USB plug
PIC PGM - wire to SHEILD of USB plug

I have submitted this question to Microchip support, but they responded by
asking me what ss-icsp was, and then don't answer any more.

Before you suggest a bootloader; there are security considerations for this
product, which means no bootloader can be used.  



2010\02\10@220223 by YES NOPE9

flavicon
face
Why not have have the PGM pin use a one pin connector that can be very  
basic.
Could even be finger trace on the edge of the PCB.  A cable with a  
dual tine fork could
slip over the finger.
What does the housing look like ?  Anyplace a small hole could allow  
access to the
PCB ?  Maybe next to the USB connector.
Gus

{Quote hidden}

2010\02\10@223555 by Xiaofan Chen

face picon face
On Thu, Feb 11, 2010 at 10:31 AM, Johansson <spam_OUTinformationTakeThisOuTspampickopack.com> wrote:
> I am developing a USB product. For different logistics reasons, I'd like to
> program the PIC18F13K50 in-circuit, after the housing is assembled.

Could you use the bootloader instead and save all the troubles?


--
Xiaofan http://mcuee.blogspot.com

2010\02\11@001630 by Matt Callow

flavicon
face
Have you considered using mini or micro USB connectors? They all have
5 connectors.

Matt

On 11 February 2010 13:31, Johansson <.....informationKILLspamspam@spam@pickopack.com> wrote:
{Quote hidden}

> -

2010\02\11@005042 by Dave Tweed

face
flavicon
face
Johansson wrote:
> Before you suggest a bootloader; there are security considerations for
> this product, which means no bootloader can be used.  

You're kidding, right? A bootloader can be a hell of a lot more secure than
giving direct access to the ICSP interface!!

-- Dave Tweed

2010\02\11@013025 by Wouter van Ooijen

face picon face
> You're kidding, right? A bootloader can be a hell of a lot more secure than
> giving direct access to the ICSP interface!!

Sure? After ICSP the security fuses can be set as tight as required.
With a bootloader there is at the very least code in your chip that can
write the code space, often it will read too.

And without a tamper-proof housing the ICSP pins are accessible anyway
(to a sufficiently motivated foo).

--

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: http://www.voti.nl/hvu

2010\02\11@032413 by Xiaofan Chen

face picon face
On Thu, Feb 11, 2010 at 11:35 AM, Xiaofan Chen <xiaofancspamKILLspamgmail.com> wrote:
> On Thu, Feb 11, 2010 at 10:31 AM, Johansson <.....informationKILLspamspam.....pickopack.com> wrote:
>> I am developing a USB product. For different logistics reasons, I'd like to
>> program the PIC18F13K50 in-circuit, after the housing is assembled.
>
> Could you use the bootloader instead and save all the troubles?
>

I mean those with encryption.
Examples:
http://www.diolan.com/pic/bootloader.html
http://www.microchip.com/forums/tm.aspx?m=126770

--
Xiaofan http://mcuee.blogspot.com

2010\02\11@032844 by Xiaofan Chen

face picon face
On Thu, Feb 11, 2010 at 2:30 PM, Wouter van Ooijen <EraseMEwouterspam_OUTspamTakeThisOuTvoti.nl> wrote:
>> You're kidding, right? A bootloader can be a hell of a lot more secure than
>> giving direct access to the ICSP interface!!
>
> Sure? After ICSP the security fuses can be set as tight as required.
> With a bootloader there is at the very least code in your chip that can
> write the code space, often it will read too.

Some bootloaders can change the configuration bits as well so that
code protection is possible.

> And without a tamper-proof housing the ICSP pins are accessible anyway
> (to a sufficiently motivated foo).
>


--
Xiaofan http://mcuee.blogspot.com

2010\02\11@041324 by Alan B. Pearce

face picon face
>Before you suggest a bootloader; there are security considerations
>for this product, which means no bootloader can be used.

I would suggest that an encrypted bootloader would be heaps more secure than
an ICSP connection ...

There is an ideal looking one being promoted on the Microchip forums at
present, using XTEA encryption.

2010\02\11@063922 by Johansson

flavicon
face
Matt:
>Have you considered using mini or micro USB connectors? They all have
>5 connectors.

That's a good idea. I have considered this and I continue to do so.

Gus:
>Why not have have the PGM pin use a one pin connector that can be very
basic.
>Could even be finger trace on the edge of the PCB.  A cable with a dual
tine fork could slip over the finger.
>What does the housing look like ?  Anyplace a small hole could allow access
to the PCB ?  Maybe next to the USB connector.

That's probably the best solution in my case. Thanks Gus!

>>Before you suggest a bootloader; there are security considerations
>>for this product, which means no bootloader can be used.

Alan B. Pearce:
>I would suggest that an encrypted bootloader would be heaps more secure
than
>an ICSP connection ...

Secure against what? In this case, it's not a problem if the product is
manipulated AFTER the firmware is in the product, because it is being
delivered to the user immediately afterwards. If the user manipulates his
own product, it's his own headache. The important thing is that no user
receives a product manipulated by someone else.
If a bootloader is used, a risk is introduced that anyone with physical
access to the product, could erase it and overwrite it with a manipulated
bootloader, which seemingly acts like the genuine bootloader, but which
filters the firmware program in different malicious ways.

Xiaofan Chen:
>I mean those with encryption.

Using encryption doesn't automatically mean that things become safe. If you
encrypt your harddrive, would that mean you can't get viruses in your
computer?


2010\02\11@072517 by Alan B. Pearce

face picon face
>Alan B. Pearce:
>>I would suggest that an encrypted bootloader would be
>heaps more secure than an ICSP connection ...
>
>Secure against what? In this case, it's not a problem if the
>product is manipulated AFTER the firmware is in the product,
>because it is being delivered to the user immediately afterwards.
>If the user manipulates his own product, it's his own headache.

I would suggest this could well become your headache, to recover such
devices afterwards ...

>The important thing is that no user receives a product
>manipulated by someone else. If a bootloader is used, a
>risk is introduced that anyone with physical access to
>the product, could erase it and overwrite it with a manipulated
>bootloader, which seemingly acts like the genuine bootloader,
>but which filters the firmware program in different malicious ways.

You mean you haven't checked out how to protect the bootloader area?

It strikes me that if you supply a product with the ICSP pins available then
the possibility of someone loading rogue software is considerably increased.
If a secure bootloader is used, the ICSP pins can be protected against
everyone but the most determined hacker, and by using your own protocol, you
can make it extremely difficult to download anything without the hacker
going the ICSP route.

If you purchased your 18F13K50 chips with the bootloader loaded by
Microchip, and set the config so that the Bootload area is write protected,
then you have a very secure setup right from the beginning, which would make
it very hard for anyone on the production line to load rogue code.

2010\02\11@074937 by Isaac Marino Bavaresco

flavicon
face
Em 11/2/2010 00:31, Johansson escreveu:
{Quote hidden}

Starting by the end...

I have a similar problem, and I solved it with a bootloader. My products
communicate through Ethernet, not USB, but the situation is the same.

I need to send firmware updates to my clients regularly, but I must
ensure that nobody steal my firmware to use in clones or upload a
counterfeit firmware to my equipment in order to copy my IP.

What I did was to create a bootloader that uses AES encryption, data CRC
checking and firmware authentication.
The firmware is sent to the  customer already encrypted. There, the
firmware is sent to the board via Ethernet (some equipment models use
TFTP, others use custom protocol).

When the bootloader receives the first firmware packet, it decrypts it
(AES), check its integrity with CRC and validates it to see if it is
authentic.
Then the bootloader invalidates the original firmware to ensure that no
half-completed update will be run and writes the firmware chunk to FLASH.

The subsequent packets are processed in the same way, but the bootloader
also checks if they belong to the same firmware as the first packet and
if they are in the correct sequence.

After the last packet is validated and programmed, the bootloader marks
the firmware as valid and reboots.


Nobody can steal my intelectual property or upload a counterfeit
firmware to my boards unless they crack my encryption or crack the
chip's code protection.

The encryption algorithm is AES, which is a proven and very secure
algorithm. The cryptographic keys are kept only in my computer (inside
the firmware-generating program, in a highly encrypted HD) and inside
the code-protected MCUs. The bootloader uses only internal RAM to store
the unencrypted firmware blocks before writing them to the FLASH.


The only draw-back is that my boot-loader is a bit large, because it
contains its own TCP/IP stack and its own AES routines. The firmware
uses its own TCP/IP stack, AES routines and cryptographic keys
(different than the bootloader's of course).


Best regards,

Isaac
__________________________________________________
Faça ligações para outros computadores com o novo Yahoo! Messenger
http://br.beta.messenger.yahoo.com/

2010\02\11@075407 by Johansson

flavicon
face
Alan B. Pearce:
>I would suggest this could well become your headache, to recover such
>devices afterwards ...

On the other hand, there is also a risk that someone could throw their
device in the toilet, which would prevent it from working and maybe they
would come back to me and request to have it replaced. Sure, there might be
an odd hacker who finds the ICSP connector interesting and attempts to do
something which destroys it, then abuses the warranty to request a
replacement, thus incurring a cost for me. But this will not happen very
often.

>You mean you haven't checked out how to protect the bootloader area?

How could I protect it against erase? All PICs can be erased, can't they?
And if they can't, the attacker could replace the PIC for a new one, and put
the spoofed bootloader into that new PIC.


2010\02\11@080815 by Isaac Marino Bavaresco

flavicon
face
Em 11/2/2010 10:25, Alan B. Pearce escreveu:
{Quote hidden}

If the part is code-protected, the part must be completely erased before
any reading or programming may take place. This way, no remnants of the
application or boot-loader are left to be used or stolen.


> If you purchased your 18F13K50 chips with the bootloader loaded by
> Microchip, and set the config so that the Bootload area is write protected,
> then you have a very secure setup right from the beginning, which would make
> it very hard for anyone on the production line to load rogue code.
>  

Individually protected bootloader area is a nice thing. Not all PICs
have it. For the ones that don't have it, one must ensure that only his
own firmware is uploaded, or else somebody my upload a firmware to steal
the bootloader and all protection is lost. By analyzing the bootloader
code, the thief may recover the cryptographic keys or algorithm and
crack open any firmware he has access.

Best regards,

Isaac

__________________________________________________
Faça ligações para outros computadores com o novo Yahoo! Messenger
http://br.beta.messenger.yahoo.com/

2010\02\11@081133 by Dave Tweed

face
flavicon
face
Johansson wrote:
> How could I protect it against erase? All PICs can be erased, can't they?
> And if they can't, the attacker could replace the PIC for a new one, and
> put the spoofed bootloader into that new PIC.

So what is it, exactly, that you're trying to secure?

It's starting to sound like you haven't fully thought this through.

-- Dave Tweed

2010\02\11@084007 by sergio masci

flavicon
face


On Thu, 11 Feb 2010, Johansson wrote:

> Xiaofan Chen:
> >I mean those with encryption.
>
> Using encryption doesn't automatically mean that things become safe. If you
> encrypt your harddrive, would that mean you can't get viruses in your
> computer?

Johansson I think you've missed the point a bit :-)

Your analogy of encrypting the harddrive is the wrong one. You should
instead be thinking of scrambling a phone conversation with someone
listening in and occationally saying something to make two friends think
the other is being rude. If the line is scrambled then the friends can't
hear understand the troublemaker.

If you used a bootloader with encryption then it becomes very hard for a
third party to "just" upload code into your device. Your bootloader will
disregard any invalid attempts to load new code into the FLASH (including
a new bootloader) if the uploader does not encrypt and send the code
CORRECTLY!!! This means that unless the person doing the modification (the
bad guy between you and your client) knows how the encryption works and
what keys to use then he is VERY EFFECTIVLY blocked from uploading new
code to your device.

It is MUCH easier to change the contents of a PIC using ICSP than it is to
change it using a bootloader with encryption.

Regards
Sergio Masci

2010\02\11@090142 by Alan B. Pearce

face picon face
>>You mean you haven't checked out how to protect the bootloader area?
>
>How could I protect it against erase? All PICs can be erased,
>can't they?

Yes they can - if you can get at the ICSP connection.

>And if they can't, the attacker could replace the PIC for a
>new one, and put the spoofed bootloader into that new PIC.

But you are missing the point. By making the ICSP connection available, by
bringing out the PGM connection, then anybody can do anything to the code in
the devices you are producing.

By having a bootloader it is possible to set most chips up so that the
bootloader is protected against erasure, and it ensures that whatever does
get downloaded is from a controlled source. The bootloader can only be
erased if the PGM connection is brought out to the outside world.

2010\02\11@131355 by Isaac Marino Bavaresco

flavicon
face
Em 11/2/2010 12:01, Alan B. Pearce escreveu:
>>> You mean you haven't checked out how to protect the bootloader area?
>>>      
>> How could I protect it against erase? All PICs can be erased,
>> can't they?
>>    
> Yes they can - if you can get at the ICSP connection.
>
>  
>> And if they can't, the attacker could replace the PIC for a
>> new one, and put the spoofed bootloader into that new PIC.
>>    
> But you are missing the point. By making the ICSP connection available, by
> bringing out the PGM connection, then anybody can do anything to the code in
> the devices you are producing.
>  

No way! If the part is code-protected, the only thing one can do is to
erase the part. After erasing then he can do whatever he wants (program,
debug, read, etc.), but the original firmware/bootloader will  not be
there anymore.

> By having a bootloader it is possible to set most chips up so that the
> bootloader is protected against erasure, and it ensures that whatever does
> get downloaded is from a controlled source. The bootloader can only be
> erased if the PGM connection is brought out to the outside world.
>  

Even if you cut the ICSP pins close to the package, somebody could
scratch the plastic to solder some wires to them. He could even unsolder
the chip and buy a new blank one.

It is not possible to ensure that nobody will damage the equipment or
erase the firmware. What you should be worried of is to protect the
intellectual property inside it. If your customer damage the equipment,
lucky you, he will need to buy a new one.


Regards,

Isaac
__________________________________________________
Faça ligações para outros computadores com o novo Yahoo! Messenger
http://br.beta.messenger.yahoo.com/

2010\02\11@173203 by Adam Field

flavicon
face
> Even if you cut the ICSP pins close to the package, somebody could
> scratch the plastic to solder some wires to them. He could even unsolder
> the chip and buy a new blank one.

Wandering a little off topic, but I'm sure some on here have seen
Flylogic's blog. If not, check out these:

http://www.flylogic.net/blog/?cat=1
http://www.flylogic.net/blog/?p=25

He is able to tear down microcontrollers layer by layer and probe the
logic underneath.

2010\02\12@035229 by Alan B. Pearce

face picon face
>> But you are missing the point. By making the ICSP connection available,
>> by bringing out the PGM connection, then anybody can do anything to the
>> code in the devices you are producing.
>
>
>No way! If the part is code-protected, the only thing one can do is to
>erase the part. After erasing then he can do whatever he wants (program,
>debug, read, etc.), but the original firmware/bootloader will  not be
>there anymore.

Exactly, but why make it easy for someone to do this, and potentially damage
the reputation of your company by loading your device with rogue code?

>> By having a bootloader it is possible to set most chips up so that the
>> bootloader is protected against erasure, and it ensures that whatever
>> does get downloaded is from a controlled source. The bootloader can only
>> be erased if the PGM connection is brought out to the outside world.
>
>
>Even if you cut the ICSP pins close to the package, somebody could
>scratch the plastic to solder some wires to them. He could even unsolder
>the chip and buy a new blank one.

Agreed, but why make it easy for them, by having all the connections openly
available?

>It is not possible to ensure that nobody will damage the equipment or
>erase the firmware. What you should be worried of is to protect the
>intellectual property inside it. If your customer damage the equipment,
>lucky you, he will need to buy a new one.

Well, there are two points here. One is if someone damages the item to a
point where it doesn't work any more then you get to sell them a new one.
Great, more money in your pocket!

But if you make it easy for someone to reprogram your device, by making all
the ICSP connections readily available, then you stand a good chance of
having your product reputation damaged by someone loading your product with
code that does rogue things. Your product looks totally undamaged, complete
ex your factory, but doesn't perform to your specification. It is YOUR
reputation that gets bad mouthed, and you sell less because of it, not more.
The problem then is that the reputation gets carried over to any other
product you produce ...

There are enough hackers out there that seem to figure this is their job for
life, that making it easy for them to do so is stupid.

2010\02\12@064549 by Isaac Marino Bavaresco

flavicon
face
Em 12/2/2010 06:52, Alan B. Pearce escreveu:
{Quote hidden}

Perhaps I'm mistaken, but I think that of the people trying to crack MCU
chips, 99.9% are trying to steal the code to make pirated products. The
only thing they may want to change are some displayable messages like
brand name or product model, to sell the product as if they created it.

The perhaps 0.1% of them that have some interest in modifying or
creating a different firmware for an existing product are trying to
adapt the product to their own needs, not trying to make your product
seem defective. I think they are mostly hobbyists and DIY guys, that are
not going to blame you for changes themselves did.


Regards,

Isaac

__________________________________________________
Faça ligações para outros computadores com o novo Yahoo! Messenger
http://br.beta.messenger.yahoo.com/

2010\02\12@065122 by Isaac Marino Bavaresco

flavicon
face
Em 11/2/2010 20:32, Adam Field escreveu:
>> Even if you cut the ICSP pins close to the package, somebody could
>> scratch the plastic to solder some wires to them. He could even unsolder
>> the chip and buy a new blank one.
>>    
> Wandering a little off topic, but I'm sure some on here have seen
> Flylogic's blog. If not, check out these:
>
> http://www.flylogic.net/blog/?cat=1
> http://www.flylogic.net/blog/?p=25
>
> He is able to tear down microcontrollers layer by layer and probe the
> logic underneath.
>  
>

Yes, I knew about them already. Fortunately it requires some equipment
and skills. Nobody is safe from such attacks, but it must be worthy the
effort for someone to try to crack a chip this way. Perhaps more likely
in the security equipment area or to be able to fraud money transfers
etc., less likely for copying the product.


Regards,

Isaac

__________________________________________________
Faça ligações para outros computadores com o novo Yahoo! Messenger
http://br.beta.messenger.yahoo.com/

More... (looser matching)
- Last day of these posts
- In 2010 , 2011 only
- Today
- New search...