Em 11/2/2010 00:31, Johansson escreveu:
> 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 I=
CSP
> connector, if possible. However, as "Single-Supply In Circuit Programming"
> (formerly known as Low-Voltage ICSP programming) needs 5 pins, the USB pl=
ug
> 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, wou=
ld
> 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 th=
is
> product, which means no bootloader can be used.  =

>   =


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=E7a liga=E7=F5es para outros computadores com o novo Yahoo! Messenger =

http://br.beta.messenger.yahoo.com/ =


-- =

http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist