<kalvin.news@gmail.com> wrote:

> Some people might argue that C++ would be just fine, but I would argue
> that it is very easy to create something that is doing something that you
> didn't intend to do. The C++ is such a clever language that I will do
> some things behind the scene (like allocate an object from the dynamic
> heap although you didn't do it explicitly) unless you are very careful
> and know what to do. So, I would rule out the C++ unless you are really competent with it.
> 

Any language that allows you to do stupid shit isn't clever at all.


> In addition to the suitable programming language you will need an
> operating system. Typically in a real-time systems you would need an
> operating system that has real-time features. However, in a safety
> critical systems you will need an OS that is simple enough to be safely
> used in a safety critical systems.
> 

Actually in Ada, if you implement enough low level stuff you could have the
runtime be your minimal OS.

Luke

Dave Nadler <drn@nadler.com> wrote:

> While I've used C# for Windows applications I haven't tried it
> on an embedded platform. For embedded projects normally I use C++ 

Good luck stripping it down to run from 256kb flash.

Jack <jack4747@gmail.com> wrote:


>> IMHO, plain C, and maybe MISRA is the way to go.
> 
> or ADA.
> But it depends on the platform and the compilers.

Australian/American Dentists/Disabilities Acts? Or do you mean, Ada? Why do
people think a name is an acronym?

Chris <xxx.syseng.yyy@gfsys.co.uk> wrote:

> 
> C# raises alarm bells here for all kinds of reasons, but what do you
> think ?...


Tell us which cars do we can avoid buying them &#128526;

Also, tell them to use Ada 2012, far superior.

On Tuesday, November 8, 2016 at 5:39:35 AM UTC-5, Clifford Heath wrote:
> On 08/11/16 06:16, Ed Prochak wrote:
[]
> >
> > So I guess my opinion is "it depends".
> 
> Ed,
> 
> You responded to my message, but not to anything I actually said.
> 
> Why?
> 
> Clifford Heath.

Sorry I should have snipped.

And I've stayed out since because I think some of this is overthinking
the problem without knowing details. (not saying you specifically).

On 08/11/16 06:16, Ed Prochak wrote:
> On Friday, November 4, 2016 at 6:13:38 PM UTC-4, Clifford Heath wrote:
>> On 05/11/16 04:03, John Speth wrote:
>>>> I've been invited to a meeting to discuss am automotive like engineering
>>>> project with a high level of safety critical requirements.
>>>>
>>>> They are using Simulink for some of the top level design work, but are
>>>> programming the whole lot in C#, with some of the code already written.
>>>> Not sure at this stage which rtos is being used, if at all.
>>>>
>>>> From what I've read, C# is a web / application / database programming
>>>> language and a quick look at the Wiki page suggests that the two
>>>> most recent versions are not approved by any international standards
>>>> organisation.
>>>>
>>>> C# raises alarm bells here for all kinds of reasons, but what do you
>>>> think ?...
>>>
>>> I agree with your negative concerns about the choice.  But from a
>>> testing point of view, any language is just as good as any other *IF* it
>>> can be proved as such through thorough testing.
>>> Every hole needs to be tested.
>>
>> Not every hole *can* be tested. You run into the halting problem,
>> first and mainly with the garbage collector. There is no way to
>> prove it will always complete "in time" for any definition of
>> "in time". The same is likely true of many of the application's
>> own algorithms; but at least you're in control of those.
>>
>> Clifford Heath.
>
> Sorry for joining late in the conversation.
>
> Actually I would say it depends on the systems architecture.
> C# is a decent GUI language. If you then assign the hard real
> time features to low level controllers (device drivers &/or
> micro controllers like Arduino), you can build a decently
> robust system.
>
> So I guess my opinion is "it depends".

Ed,

You responded to my message, but not to anything I actually said.

Why?

Clifford Heath.

On 08/11/16 09:00, Paul Rubin wrote:
> Tom Gardner <spamjunk@blueyonder.co.uk> writes:
>> Please read what I wrote. I did not suggest writing the /application/
>> in assembler.
>
> The Java applets on the card are what I mean by the application.  It
> does things like manage PKI credentials, etc.  I don't know if phone
> contacts on sim cards are usually implemented with applets.
>
> Yes, crypto primitives are done with assembly code and/or hardware
> accelerators on the card.  Your Java applet can them through appropriate
> interfaces.
>
>> Having said that, my suspicion is that the /applications/ on JavaCards
>> are so simple that they /could/ be coded in assembler
>
> I think you have a picture of these applets being coded by the card
> manufacturer.  But it's usually the client application developer who
> codes them.  Who expects to expect them to progam the cards in
> assembler?  Java makes life a lot easier even if assembler were
> feasible.

Oh yes indeed; I use assembler as an extreme - which I
suspect would be practical (even if not desirable!) for
the simple apps I /imagine/ being on a JavaCard.

I'd welcome use cases of apps with complex logic, where the
same end result couldn't reasonably be achieved by simply
passing a magic number to a server.


>> but I wouldn't push that point. It could be easily countered by
>> outlining an application that was /necessarily/ too complex for that
>> to be reasonable.
>
> PKCS11 token, one of the driving applications for javacard.  Spec is
> linked from here:
>
>    https://www.cryptsoft.com/pkcs11doc/
>
> The "base" spec is a 150 page pdf and then there's some extensions in
> separate documents.  There's a ton of code involved.  But, I don't know
> how much of it has to be on the card itself.
>
> G10 also offers PGP/GPG key management smart cards.
>
> These cards run complex protocols--they're not just running some number
> through AES and sending back the answer.

I certainly haven't got time or inclination to read that!

A /quick/ skim didn't indicate compelling use cases, let
alone for complex logic in the JavaCard.

As I said, examples would be welcome.


>> Sigh. Please use some common sense about what "sufficiently complex to
>> warrant" might mean.  Hint: a googling leads to the first definition
>> of warrant as a verb: "justify or necessitate (a course of action)."
>
> I certainly think using Javacard is justified when faced with the much
> larger hassle and vulnerability surface of using assembler.  That is
> true even of very small applications.  The payment card and mobile phone
> industries use billions of javacards for a reason, not because they were
> hoodwinked by marketing crap.

Oh yes indeed. But convenience is one thing, necessity another.


>> I would be interested in whether there are any real-world cases of
>> multiple applications for different corporations on the same JavaCard.
>
> Payment credentials for more than one bank account or credit card.

Only if from different companies (e.g. banks). Multiple
accounts with the same institution can be dealt with by
a single magic number.

After all, when Javacards aren't involved, I simply
login to a bank once, and then fettle with all my
accounts in that bank simultaneously.


>>> You mean like Java?  ;-)
>> Yes, as one of several.
>
> If you prefer BASIC, try basiccard.com.  I have some of these.  The
> cards aren't as flexible but the dev kit is cheaper.

OK, if I argue from one extreme, I can't complain if
you use others :)

Tom Gardner <spamjunk@blueyonder.co.uk> writes:
> Please read what I wrote. I did not suggest writing the /application/
> in assembler.

The Java applets on the card are what I mean by the application.  It
does things like manage PKI credentials, etc.  I don't know if phone
contacts on sim cards are usually implemented with applets.

Yes, crypto primitives are done with assembly code and/or hardware
accelerators on the card.  Your Java applet can them through appropriate
interfaces.

> Having said that, my suspicion is that the /applications/ on JavaCards
> are so simple that they /could/ be coded in assembler

I think you have a picture of these applets being coded by the card
manufacturer.  But it's usually the client application developer who
codes them.  Who expects to expect them to progam the cards in
assembler?  Java makes life a lot easier even if assembler were
feasible.

> but I wouldn't push that point. It could be easily countered by
> outlining an application that was /necessarily/ too complex for that
> to be reasonable.

PKCS11 token, one of the driving applications for javacard.  Spec is
linked from here:

  https://www.cryptsoft.com/pkcs11doc/

The "base" spec is a 150 page pdf and then there's some extensions in
separate documents.  There's a ton of code involved.  But, I don't know
how much of it has to be on the card itself.

G10 also offers PGP/GPG key management smart cards.

These cards run complex protocols--they're not just running some number
through AES and sending back the answer.

> Sigh. Please use some common sense about what "sufficiently complex to
> warrant" might mean.  Hint: a googling leads to the first definition
> of warrant as a verb: "justify or necessitate (a course of action)."

I certainly think using Javacard is justified when faced with the much
larger hassle and vulnerability surface of using assembler.  That is
true even of very small applications.  The payment card and mobile phone
industries use billions of javacards for a reason, not because they were
hoodwinked by marketing crap.

> I would be interested in whether there are any real-world cases of
> multiple applications for different corporations on the same JavaCard.

Payment credentials for more than one bank account or credit card.

>> You mean like Java?  ;-)
> Yes, as one of several.

If you prefer BASIC, try basiccard.com.  I have some of these.  The
cards aren't as flexible but the dev kit is cheaper.

On 08/11/16 05:29, Paul Rubin wrote:
> Tom Gardner <spamjunk@blueyonder.co.uk> writes:
>> True, but surely a different magic number (derived from the hidden
>> magic number) /is/ transmitted. The derivation is not sufficiently
>> complex to benefit from having Java in the card: either there is
>> hardware assistance or it is highly optimised assembler.
>
> Wait, you were the guy saying C++ is dangerous and now you're saying to
> write critical security applications in assembler?  :-O

Please read what I wrote. I did not suggest writing
the /application/ in assembler.

Frequently the crypto routines are written in highly
optimised assembler (even if that optimisation is
done by tweaking the C and compiler flags, and
examining the object code :) ) That's not a problem
since all aspects of the algorithm are well defined
and the algorithm itself is simple.

Those characteristics mean writing the crypto routines
in assembler is very tractable and often beneficial.

Having said that, my suspicion is that the /applications/
on JavaCards are so simple that they /could/ be coded
in assembler - but I wouldn't push that point. It could
be easily countered by outlining an application that was
/necessarily/ too complex for that to be reasonable.


>> sufficiently complex to warrant Java or another OOP+libraries.
>
> What does "sufficiently complex" mean?  If I have to write a hello world
> program I have no trouble using C++ or some other huge language for it.
> Is C++ "warranted"?  Probably not, but using it doesn't cost me
> anything, so what the hey.

Sigh. Please use some common sense about what
"sufficiently complex to warrant" might mean.
Hint: a googling leads to the first definition
of warrant as a verb: "justify or necessitate
(a course of action)."


>> The JavaCard app is so small that it would be easy to write in
>> assembler!
>
> Part of the Javacard vision (I don't know how much it caught on, but it
> gets at least some use) was to have multiple applications on the card,
> that can't access each other's data.  Assembly code would be able to get
> at everything in the card instead of just that application's data.  You
> need some kind of application sandboxing and the Java applet model works
> nicely for that.

I agree with that assessment. I would be interested in
whether there are any real-world cases of multiple
applications for different corporations on the same
JavaCard.

Different corporations is necessary, if you think
about it.


>> Any support environment implementation would only be written once, by
>> the card manufacturer,
>
> That locks you in with that card manufacturer, while you can move your
> javacard code around between cards easily.

Yes, in theory. I wonder how often that is a benefit,
in practice.


>> and could be written in any convenient language.
>
> You mean like Java?  ;-)

Yes, as one of several.

Tom Gardner <spamjunk@blueyonder.co.uk> writes:
> True, but surely a different magic number (derived from the hidden
> magic number) /is/ transmitted. The derivation is not sufficiently
> complex to benefit from having Java in the card: either there is
> hardware assistance or it is highly optimised assembler.

Wait, you were the guy saying C++ is dangerous and now you're saying to
write critical security applications in assembler?  :-O

> sufficiently complex to warrant Java or another OOP+libraries.

What does "sufficiently complex" mean?  If I have to write a hello world
program I have no trouble using C++ or some other huge language for it.
Is C++ "warranted"?  Probably not, but using it doesn't cost me
anything, so what the hey.

Similarly, Javacard is a fairly simple bytecode interpreter and virtual
machine.  The interpreter consumes some program rom on the chip, and
there is some ram overhead for the applets and their data, but it's not
that big a fraction of the chip cost.

> The JavaCard app is so small that it would be easy to write in
> assembler!

Part of the Javacard vision (I don't know how much it caught on, but it
gets at least some use) was to have multiple applications on the card,
that can't access each other's data.  Assembly code would be able to get
at everything in the card instead of just that application's data.  You
need some kind of application sandboxing and the Java applet model works
nicely for that.

> Any support environment implementation would only be written once, by
> the card manufacturer,

That locks you in with that card manufacturer, while you can move your
javacard code around between cards easily.

> and could be written in any convenient language.

You mean like Java?  ;-)